Stable Cryptocurrency Coinage

ABSTRACT

A multi-coin mechanism for maintaining a stable value of cryptographic coinage traded in a decentralized market exchange without requiring a reserve. Multiple, pegged cryptographic tokens are traded in the reserveless decentralized market exchange. Each of the multiple, pegged cryptographic tokens may be pegged to a different asset (such as different currencies and/or commodities). The multiple, pegged cryptographic tokens are value related based on cryptographic exchange rates. Whenever a market transaction is processed (such as a buy or sell order), at least one of a destruction operation and a creation operation are performed. The destruction operation destroys at least one of the pegged cryptographic tokens, while the creation operation creates new ones of the pegged cryptographic tokens n. The multi-coin mechanism thus implements a decentralized and algorithmic monetary policy that removes and/or deposits cryptographic tokens to/from the reserveless decentralized market exchange to alter supply and to maintain stable coinage values.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a divisional filing of U.S. application Ser.No. 16/351,592 filed Mar. 13, 2019, since issued as U.S. patent ______,and incorporated herein by reference in its entirety. This patentapplication also claims domestic benefit of U.S. Provisional ApplicationNo. 62/774,357 filed Dec. 3, 2018 and of U.S. Provisional ApplicationNo. 62/723,595 filed Aug. 28, 2018, with both provisional patentapplications incorporated herein by reference in their entireties. Thispatent application also claims domestic benefit of U.S. ProvisionalApplication No. 62/714,909 filed Aug. 6, 2018 and of U.S. ProvisionalApplication No. 62/714,911 filed Aug. 6, 2018, with both provisionalpatent applications incorporated herein by reference in theirentireties.

BACKGROUND

Cryptographic coinage and blockchains are growing in usage. As usagegrows, however, volatility has become a problem. The markets forcryptographic coinage have become highly speculative and extreme pricevariations are hindering mainstream adoption.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments areunderstood when the following Detailed Description is read withreference to the accompanying drawings, wherein:

FIGS. 1-7 are simplified illustrations of stability mechanisms forcryptographic coinage in a blockchain environment;

FIGS. 7-10 are more detailed illustrations of an operating environment,according to exemplary embodiments;

FIGS. 11-13 illustrate a below-target scenario, according to exemplaryembodiments;

FIGS. 14-15 illustrate an above-target scenario, according to exemplaryembodiments;

FIG. 16 illustrates indexing of cryptographic coinage, according toexemplary embodiments;

FIGS. 17-18 illustrate blockchain recordations, according to exemplaryembodiments;

FIGS. 19-20 illustrate a blockchain data layer, according to exemplaryembodiments;

FIGS. 21-25 further illustrate the blockchain data layer, according toexemplary embodiments

FIG. 26 illustrates fraud detection, according to exemplary embodiments;

FIG. 27 illustrates monetary policy based on the blockchain data layer,according to exemplary embodiments;

FIGS. 28-34 illustrate a network of multiple cryptographic peggedtokens, according to exemplary embodiments;

FIGS. 35-36 further illustrate algorithmic decentralized monetarypolicy, according to exemplary embodiments;

FIG. 37 is a flowchart illustrating a method or algorithm for stablepricing of cryptographic coinage, according to exemplary embodiments;and

FIGS. 38-39 depict still more operating environments for additionalaspects of the exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafterwith reference to the accompanying drawings. The exemplary embodimentsmay, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Theseembodiments are provided so that this disclosure will be thorough andcomplete and will fully convey the exemplary embodiments to those ofordinary skill in the art. Moreover, all statements herein recitingembodiments, as well as specific examples thereof, are intended toencompass both structural and functional equivalents thereof.Additionally, it is intended that such equivalents include bothcurrently known equivalents as well as equivalents developed in thefuture (i.e., any elements developed that perform the same function,regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill inthe art that the diagrams, schematics, illustrations, and the likerepresent conceptual views or processes illustrating the exemplaryembodiments. The functions of the various elements shown in the figuresmay be provided through the use of dedicated hardware as well ashardware capable of executing associated software. Those of ordinaryskill in the art further understand that the exemplary hardware,software, processes, methods, and/or operating systems described hereinare for illustrative purposes and, thus, are not intended to be limitedto any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless expressly stated otherwise. Itwill be further understood that the terms “includes,” “comprises,”“including,” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. It will be understood thatwhen an element is referred to as being “connected” or “coupled” toanother element, it can be directly connected or coupled to the otherelement or intervening elements may be present. Furthermore, “connected”or “coupled” as used herein may include wirelessly connected or coupled.As used herein, the term “and/or” includes any and all combinations ofone or more of the associated listed items.

It will also be understood that, although the terms first, second, etc.may be used herein to describe various elements, these elements shouldnot be limited by these terms. These terms are only used to distinguishone element from another. For example, a first device could be termed asecond device, and, similarly, a second device could be termed a firstdevice without departing from the teachings of the disclosure.

FIGS. 1-7 are simplified illustrations of stability mechanisms forcryptographic coinage 20 in a blockchain environment 22, according toexemplary embodiments. Here exemplary embodiments may create, and/ordestroy, the cryptographic coinage 20 to maintain a stable price orvalue as to a target value 24. For example, an issuing authority 26 maycreate or issue one or more pegged cryptographic tokens (or “PT”) 28and/or one or more variable-priced cryptographic tokens (or “VT”) 30.Each pegged cryptographic token 28 and each variable-pricedcryptographic token 30 is preferably freely and independently traded ina market exchange 32, but the market exchange 32 is not necessary.Regardless, cryptographic exchange rates 34 define or establish relativevalues between the pegged cryptographic token(s) 28 and thevariable-priced cryptographic token(s) 30. That is, the cryptographicexchange rates 34 allow the value of any pegged cryptographic token 28to be determined, converted, and/or exchanged into another one of thepegged cryptographic tokens 28 and/or into the variable-pricedcryptographic token 30 and vice versa.

FIG. 1 also illustrates a network 220 of the cryptographic pegged tokens28. While there may be many different pegged cryptographic tokens (suchas any numeral N), FIG. 1 only illustrates a simple example of three (3)cryptographic pegged tokens (illustrated as reference numerals 28 a-c).Each pegged cryptographic token 28 a-c may be tied, or pegged, to anytradeable asset, such as any currency (e.g., the US Dollar, the ChineseYen, the Euro), a commodity (e.g., oil, gold, silver), or property(e.g., real estate, intellectual, jewelry, antiques). Each peggedcryptographic token 28 a-c may thus have its corresponding currentmarket value 44 a-c in the market exchange 32. Each pegged cryptographictoken 28 a-c may also have its corresponding target value 24 a-c.

The network 220 of the cryptographic pegged tokens 28 may be traded.That is, any of the pegged cryptographic token 28 a-c may be bought,sold, traded, and/or converted. Any one of the cryptographic peggedtokens 28 may be exchanged between any other, and/or to any other,according to their relative cryptographic exchange rates 34, within theissuing authority 26 (e.g., the protocol or central authority of themarket exchange 32). Because the cryptographic pegged tokens 28 a-c mayfluctuate in value, there may be multiple cryptographic exchange rates34 when valuing/trading/converting between any of the cryptographicpegged tokens 28 a-c and/or the variable-priced cryptographic token 30(as earlier explained). Even though the current market value 44 of thevariable-priced cryptographic token 30 may fluctuate, thevariable-priced cryptographic token 30 may have zero arbitrageopportunities. That is, its current market value 44 of thevariable-priced cryptographic token 30 is whatever its market value is.The current market values 44 a-c of the cryptographic pegged tokens 28a-c, however, may vary, especially when compared to each other. Forexample, suppose the current market value 44 a of the cryptographicpegged token 28 a exceeds its target value 24 a, but the current marketvalue 44 b of the cryptographic pegged token 28 b is less than itstarget value 24 b. Traders in the market exchange 32 thus see anarbitrage advantage to trade/convert/sell the cryptographic pegged token28 a to reap a profit, and the traders see a buy opportunity to acquirethe cryptographic pegged token 28 b. The traders, in other words, maysee the arbitrage opportunity is greater between the pegged tokens 28 aand 28 b as opposed to the variable-priced cryptographic token 30, whichmeans that the whole network 220 has a more enhanced stability toleverage the differences between the pegged tokens 28 a and 28 b againsteach other instead of being restricted to just the variable-pricedcryptographic token 30.

The network 220 of the cryptographic pegged tokens 28 increasesarbitrage opportunities. Any one of the cryptographic pegged tokens 28may be exchanged between any other, and/or to any other, according totheir relative cryptographic exchange rates 34, within the issuingauthority 26 (e.g., the protocol or central authority of the marketexchange 32). Indeed, the issuing authority 26 may permitexchange/conversion as long as there is no difference in their marketvalues 44. If those cryptographic pegged tokens 28 are available on theprotocol (e.g., the market exchange 32) and one token 28 a is high and adifferent token 28 b is low, an exchange (such as the high token 28 afor the low token 28 b on the market exchange 32) may be permitted.Indeed, the same conversion may be made inside of a user's electronicwallet. For example, suppose the cryptographic pegged token 28 a is 5%high and the cryptographic pegged token 28 b is 2% low. An arbitrageopportunity of 7% exists between the cryptographic pegged tokens 28 aand 28 b. The variable-priced cryptographic token 30 would always bespot on, so the user/trader only has an arbitrage opportunity of either5% or 2%. The 2% low cryptographic pegged token 28 b, however, may notreally be adjusted because there is not enough room there to get a goodreturn on the trades because there are other costs in trading. But if anarbitrage opportunity of 7% exists, then an acceptable (perhaps minimum)return is present, even including trading costs/fees. That acceptablearbitrage opportunity of 7% helps to adjust the 2% low cryptographicpegged token 28 b up and decrease the market value 44 of the 5% highcryptographic pegged token 28 a. The acceptable arbitrage opportunityalso takes stress off of the variable-priced cryptographic token 30. Theacceptable, minimum return has a lot of variables (e.g., some may accepta profit at 1%, whereas other users may need 15% or 20% profit). If anycryptographic pegged token 28 is extremely, extremely volatile, then aparticular margin may be required to protect from the idea that it mighteither fall or increase in value before cashing out, in which case theadvantages may not be realized.

The issuing authority 26 may perform synthetic pairing. Because thevalues of the pegged cryptographic tokens 28 and/or the variable-pricedcryptographic token 30 may be related (perhaps via the cryptographicexchange rate 34), any of the pegged cryptographic tokens 28 and/or thevariable-priced cryptographic token 30 may be termed a synthetic pair 36and their supply may be managed using a creation operation 38 and/or adestruction operation 40. For example, any user or holder of thevariable-priced cryptographic token(s) 30 may request that the issuingauthority 26 covert a certain number of her variable-pricedcryptographic tokens 30 to any of the pegged cryptographic token(s) 28,perhaps on demand, at the current cryptographic exchange rate 34. Here,though, exemplary embodiments may perform the destruction operation 40to destroy the user's requested number of her variable-pricedcryptographic token(s) 30 and also perform the creation operation 38 tocreate an equivalent number of the pegged cryptographic tokens 28, asdetermined by the current cryptographic exchange rate 34. In plainwords, exemplary embodiments destroy the user's requested number of hervariable-priced cryptographic tokens 30 and create the equivalent numberof the pegged cryptographic tokens 28.

FIG. 2 illustrates additional synthetic pairing. Here the user or holdermay request that the issuing authority 26 covert a certain number of herpegged cryptographic tokens 28 to the equivalent number of thevariable-priced cryptographic tokens 30, perhaps on demand, again at thecurrent cryptographic exchange rate 34. The issuing authority 26 maythus perform the destruction operation 40 to destroy the user'srequested number of her pegged cryptographic tokens 28 and also performthe creation operation 38 to create the equivalent number of thevariable-priced cryptographic tokens, as determined by the currentcryptographic exchange rate 34.

Additional arbitrage opportunities are available. As any of the peggedcryptographic tokens 28 a-c are bought/sold/traded/exchanged, theirsupply may be managed using the creation operation 38 and/or thedestruction operation 40. For example, the issuing authority 26 mayconvert a certain number of the pegged cryptographic token 28 a into thepegged cryptographic token 28 b, perhaps on demand, at the currentcryptographic exchange rate 34. That is, the issuing authority 26 mayperform the destruction operation 40 to destroy a certain number thepegged cryptographic tokens 28 a and also perform the creation operation38 to create an equivalent number of the pegged cryptographic token 28b, as determined by the current cryptographic exchange rate 34. Theissuing authority 26, vice versa, may perform the destruction operation40 to destroy a certain number the pegged cryptographic token 28 b andalso perform the creation operation 38 to create an equivalent number ofthe pegged cryptographic tokens 28 a. The issuing authority 26 may thususe the creation operation 38 and/or the destruction operation 40 tomaintain a supply of the pegged cryptographic tokens 28 a and/or 28 b asstability mechanisms. The creation operation 38 and/or the destructionoperation 40 may also be implemented between the pegged cryptographictokens 28 a and 28 c and between 28 b and 28 c.

Exemplary embodiments thus eliminate reserves. Conventional stablecoinmechanisms are backed by fiat reserves or traditional assets. Exemplaryembodiments, in contradistinction, eliminate any reserve requirement byleveraging the ability to create, issue, and destroy the peggedcryptographic tokens 28 and/or the variable-priced cryptographic tokens30, according to the cryptographic exchange rate 34 as determined by thefree market exchange 32. Simply put, the issuing authority 26financially or reputationally backs the pegged cryptographic tokens 28,perhaps using the variable-priced cryptographic tokens as an indirectreserve 42.

Exemplary embodiments thus present a simple and elegant solution forstable values of the cryptographic coinage 20. The indirect reserve 42has the advantage of seigniorage shares, without the complexity. Thatis, exemplary embodiments elastically manage the supply of the peggedcryptographic tokens 28 and the variable-priced cryptographic tokens 30in a decentralized fashion, without large and cumbersome collateralrequirements and complex algorithmic regulations. Seigniorage shares actlike a central bank to issue stable tokens, but seigniorage sharesassumes that the basis of the issuance is a token outside the control ofa smart contract. Here, the indirect reserve 42 assumes the issuingauthority 26 has control of both the pegged cryptographic token 28 andthe variable-priced cryptographic token 30. By playing off thevolatility of the variable-priced cryptographic token 30 against thepegged cryptographic token 28, the indirect reserve 42 is able toleverage game theory and arbitrage to get the free market exchange 32 toforce the pegged cryptographic token 28 to match its target value 24.

Exemplary embodiments satisfy the goals for a stablecoin mechanism. Thepegged cryptographic token 28 should be secure against crashes,decentralized, and collaterally efficient. The indirect reserve 42 isalways able to meet its obligations, because the issuing authority 26,by definition, has the management power and authority to create and todestroy the supply of the variable-priced cryptographic tokens 30 andthe pegged cryptographic tokens 28. There are no reserves to run out,and the issuing authority 26 may also match any obligation. Themechanisms for conversion between the variable-priced cryptographictokens 30 and the pegged cryptographic tokens 28 are completelydistributed and autonomous, thus satisfying the goal ofdecentralization. Moreover, the pegged cryptographic tokens 28 arecreated as collateral in the variable-priced cryptographic tokens 30 anddestroyed in one direction, while the variable-priced cryptographictokens 30 are created as collateral in the pegged cryptographic tokens28 and destroyed in the other direction, so no collateral is actuallyheld or required by the issuing authority 26. Simply put, the issuingauthority 26 never runs out of, or exhausts, or overleverages, itscollateral, so the issuing authority 26 may always respond to andexecute buy/sell/trade orders from clients. Exemplary embodimentseliminate any need for auctioned bonds.

FIG. 3 illustrates a below-target scenario. Here a current market value44 of the pegged cryptographic token 28 lags, or trails, the desiredtarget value 24. Put another way, if the pegged cryptographic token 28is trading low, then a demand 46 for the pegged cryptographic token 28is low and devalued (perhaps relative to a different one of the peggedcryptographic tokens 28 and/or to the variable-priced cryptographictoken 30). Traders see a buy opportunity in the pegged cryptographictoken 28, while holders of the different one of the pegged cryptographictokens 28 and/or the variable-priced cryptographic token 30 see a sellopportunity to reap a profit. The holders will sell or exchange aquantity of their different one of the pegged cryptographic tokens 28and/or the variable-priced cryptographic token 30 for an equivalentnumber of the pegged cryptographic tokens 28 (according to thecryptographic exchange rate 34), thus realizing the profit. The issuingauthority 26, acting in concert with the free market exchange 32,jointly operate as a powerful stabilizing force for the peggedcryptographic token 28. Exemplary embodiments may thus enforceindependent trading platforms like exchanges through arbitrage to createa Schelling point at the target value 24 of the pegged cryptographictoken 28.

Stabilization may occur. Because a profit opportunity exists, holderssell or exchange any of the cryptographic tokens 28 or 30 for anequivalent number of the pegged cryptographic tokens 28 (according tothe cryptographic exchange rate 34), thus realizing the profit. As thesales/exchanges are processed, the population pool or quantity of thevariable-priced cryptographic tokens 30 in the market exchange 32 isreduced (perhaps due to the destruction operation 40) and the populationquantity or pool of the pegged cryptographic tokens 28 (e.g., a totalnumber in usage or issuance) increases in the market exchange 32(perhaps due to the creation operation 38). As the cryptocoinageexchange proceeds, the issuing authority 26 and/or the market exchange32 may monitor the population supplies of the variable-pricedcryptographic tokens 30, the pegged cryptographic tokens 28, theircurrent market values 44, and their target values 24. If too manyvariable-priced cryptographic tokens 30 are sold or exchanged anddestroyed, there may be a greater number of the pegged cryptographictokens 28 than desired (due to the creation operation 38 and/or thedestruction operation 40) and an oversupply condition may exist.Simultaneously, or nearly simultaneously, the issuing authority 26and/or the market exchange 32 may cooperate to reduce, or withdraw, thepegged cryptographic tokens 28 from the market exchange 32. The issuingauthority 26, in other words, performs the destruction operation 40 towithdraw and destroy a desired quantity of the pegged cryptographictokens 28 from the market exchange 32 to stabilize its current marketvalue 44 to the target value 24. At nearly the same time, the issuingauthority 26 may also perform the creation operation 38 to create adesired quantity of the variable-priced cryptographic tokens 30 andinjects, or deposits, the newly-created variable-priced cryptographictokens 30 into the market exchange 32, thus replenishing its populationsupply. These trades/exchanges may happen without delays imposed bydeposits and withdraws as long as balances are setup ahead of time bythe trader. Trades on the market exchange 32 and with the issuingauthority 26 may be executed in parallel. Once the trades are executedand recorded (perhaps to blockchains 48 a and/or 48 b, as laterparagraphs will explain), the issuing authority 26 deposits orreplenishes the population supply or balance of the variable-pricedcryptographic tokens 30 into the market exchange 32 to set the marketexchange 32 up for the next arbitrage opportunity.

Exemplary embodiments thus stabilize the pegged cryptographic token 28.Because the exchange of the pegged cryptographic token 28 for thevariable-priced cryptographic token 30 could vary greatly over time, theissuing authority 26 ensures enough variable-priced cryptographic tokens30 are injected/provided for any transaction. These variable-pricedcryptographic tokens 30 are created and the pegged cryptographic tokens28 are destroyed. Moreover, the issuing authority 26 may also create anyamount of the variable-priced cryptographic tokens 30 that are needed tomaintain an equilibrium between the current market value 44 and thetarget value 24 of the pegged cryptographic token 28.

Exemplary embodiments use market forces. If the pegged cryptographictoken 28 is trading low, then traders/holders in the market exchange 32consider the pegged cryptographic token 28 to be devalued relative tothe variable-priced cryptographic token 30. The market exchange 32 mayhave a pool of the pegged cryptographic tokens 28 and another pool ofthe variable-priced cryptographic tokens 30. The issuing authority 26(e.g., a protocol or central authority off the market exchange 32) alsohas additional pools of the pegged cryptographic tokens 28 and thevariable-priced cryptographic tokens 30. When the pegged cryptographictoken 28 is devalued by the market exchange 32, its demand 46 is low andtraders/holders will have a profit incentive to buy the peggedcryptographic token 28 at its low current market price or value 44, thusconverting the pegged cryptographic token 28 to its equivalent number ofvariable-priced cryptographic tokens 30 (according to the cryptographicexchange rate 34). Because the issuing authority 26 may monitor thetotal number of the variable-priced cryptographic tokens 30, the issuingauthority 26 may also, nearly simultaneously, buy an excess number ofthe variable-priced cryptographic tokens 30 to maintain a consistentsupply or pool of the variable-priced cryptographic tokens 30. Recallthat a buy order destroys the variable-priced cryptographic tokens 30and creates or gains more pegged cryptographic tokens 28. Simply put,anytime a trader/holder and/or the issuing authority 26 can make money,market forces will push the current market price or value 44 up. Anincreasing market value 44 concomitantly increases the demand 46 of thepegged cryptographic token 28, thus bringing the current market value 44toward the target value 24.

FIG. 4 illustrates an above-target scenario. Here the current, marketvalue 44 of the pegged cryptographic token 28 is greater or higher thanits desired target value 24. The demand 46 for the pegged cryptographictoken 28 is increasing, so the pegged cryptographic token 28 mayeventually be overvalued relative to the variable-priced cryptographictoken 30 and/or to its target price or value 24. Holders of the peggedcryptographic token 28 have the sell opportunity to reap a profit, whiletraders see the buy opportunity in the variable-priced cryptographictoken 30. The holders sell or exchange their pegged cryptographic tokens28 for an equivalent number of the variable-priced cryptographic tokens30 (according to the cryptographic exchange rate 34), thus realizing theprofit. As the sales/exchanges are processed, the demand 46 for thepegged cryptographic token 28 decreases, thus reducing its currentmarket value 44 toward its target value 24. Moreover, the demand 46 forthe variable-priced cryptographic token 30 increases, thus increasingits current market value 44.

Population control may also be implemented. As the holders of the peggedcryptographic token 28 sell, the population pool or quantity of thepegged cryptographic tokens 28 in the market exchange 32 decreases. Asthe coinage trades proceed, the issuing authority 26 and/or the marketexchange 32 may monitor the population supplies of the variable-pricedcryptographic tokens 30, the pegged cryptographic tokens 28, theircurrent market values 24, and their target values 24. If too many peggedcryptographic tokens 28 are sold or exchanged and destroyed, there maybe a greater number of the variable-priced cryptographic tokens 30 thandesired (due to the creation operation 38 and/or the destructionoperation 40) and the oversupply condition may exist. Simultaneously, ornearly simultaneously, the issuing authority 26 and/or the marketexchange 32 may cooperate to reduce, or withdraw, the variable-pricedcryptographic tokens 30 from the market exchange 32. The issuingauthority 26, in other words, performs the destruction operation 40 todestroy a desired quantity of the variable-priced cryptographic tokens30 from the market exchange 32 to stabilize its current market value 44to the target value 24. At nearly the same time, the issuing authority26 performs the creation operation 38 to create a desired quantity ofthe pegged cryptographic tokens 28 and injects, or deposits, thenewly-created pegged cryptographic tokens 28 into the market exchange32, thus replenishing its population supply. These trades may then berecorded to the blockchain 48 (as later paragraphs will explain).

Market forces again prevail. If the value of the pegged cryptographictoken 28 is high compared to its target value 24 and/or thevariable-priced cryptographic token 30, then the pegged cryptographictoken 28 may be sold on the market exchange 32 for the variable-pricedcryptographic token 30. This sell operation results in a greater amountof the variable-priced cryptographic tokens 30 than the peggedcryptographic token 28 should allow. At the same time, a lesser amountof the variable-priced cryptographic tokens 30 can be exchanged for thesame pegged cryptographic tokens 28 by the issuing authority 26, thusreplenishing the supply of the pegged cryptographic tokens 28 in themarket exchange 32.

The issuing authority 26 may thus be a market participant. However, theissuing authority 26 may participate for opposite market effects. Whenthe issuing authority 26 trades between the pegged cryptographic tokens28 and the variable-priced cryptographic tokens 30, the market effect ofthese trades is opposite to the trades on the market exchange 32.Suppose, for example, that a large number of the variable-pricedcryptographic tokens 30 were sold for between the pegged cryptographictokens 28 on the market exchange 32. The price of the variable-pricedcryptographic token 30 necessarily goes down as the trade(s) consumesthe order book for the variable-priced cryptographic token 30. On theother hand, a large number of the variable-priced cryptographic tokens30 exchanged for the pegged cryptographic tokens 28 using the issuingauthority 26 reduces the supply of the variable-priced cryptographictokens 30 by that amount. Lowering the supply of the variable-pricedcryptographic tokens 30 eventually increases the current market price 44of the variable-priced cryptographic tokens 30. So, as the peggedcryptographic token 28 becomes popular as a stable value, the demand 46for the pegged cryptographic token 28 is likely to rise, but the onlyway to create a bigger supply of the pegged cryptographic token 28 isthrough the conversation of the variable-priced cryptographic token 30to the pegged cryptographic token 28, which lowers the supply of thevariable-priced cryptographic token 30. On the other hand, if the valueof the variable-priced cryptographic token 30 is in question and fallsin the market exchange 32, conversion to the pegged cryptographic token28 becomes attractive. All of these operations (e.g., the creationoperation 38 and the destruction operation 40) increase the value of thevariable-priced cryptographic token 30. As the value of thevariable-priced cryptographic token 30 goes up, market participants willpurchase the variable-priced cryptographic token 30 and thus furtherincrease its value. But the demand 46 may also trigger the conversion ofthe pegged cryptographic token 28 to the variable-priced cryptographictoken 30, and that conversion may dampen the growth in value of thevariable-priced cryptographic token 30 by increasing the supply.

Market arbitrage may be autonomous. The blockchain 48 a may includeso-called smart or digital contracts 50 that self-execute buy/selltrades according to predefined contractual parameters. The blockchain 48may thus monitor the current market values 44 and/or the target values24 for the variable-priced cryptographic token 30 and the peggedcryptographic token 28 and execute pre-defined buy and sell orders.Digital contracts 50 may thus be automated traders that buy and sell thecryptographic tokens 28 and 30. An entity or party may thus acquire moreof the cryptographic tokens 28 and 30 than desired, while at the sametime selling/destroying the cryptographic tokens 28 and 30 for a profit.The entity or party may thus configure their smart or digital contracts50 to achieve financial goals, yet exemplary embodiments ensure that thecurrent market value 44 and the target value 24 are stable and lesslikely to vary.

Exemplary embodiments are bondless. Neither the buyer, seller, nor theissuing authority 26 is required to post or provide a financial or coinbond, security, or other asset. Simply put, any party or entity, whethercompany, corporation, or individual person, may participate in themarket exchange 32 and buy or sell the variable-priced cryptographictoken 30 and the pegged cryptographic token 28. Indeed, exemplaryembodiments may be applied to the market exchange 32 having a smallnumber of only two (2) players or hundreds, thousands, or millions ofparticipants.

FIG. 5 further illustrates the pegged cryptographic token 28. As thisdisclosure above explained, the pegged cryptographic token 28 and thevariable-priced cryptographic token 30 may have related values. Thepegged cryptographic token 28, in other words, may be anencryption-secured digital medium of exchange whose value (e.g., thetarget value 24) is tied to some other asset or medium of exchange. Thepegged cryptographic token 28, in particular, may be linked to anynation's currency 52 (such as the United States Dollar). The peggedcryptographic token 28, however, may be based on other assets, such asgold and other precious metals or even one or more other cryptographiccoins. FIG. 5, for example, illustrates a reference cryptographic token(or “RT”) 54 which may also be freely traded on the market exchange 32.The market exchange 32 may thus establish or set the values of thevariable-priced cryptographic token 30 and the pegged cryptographictoken 28 in relative terms to the reference cryptographic token 54. Thecryptographic exchange rate 34, in other words, may be defined based onthe relative values between the pegged cryptographic token 28, thevariable-priced cryptographic token 30, and the reference cryptographictoken 54. The reference cryptographic token 54 may thus only be used asa reference point. The pegged cryptographic token 28 may be valued inrelation to the Consumer Price Index (“CPI”) adjusted to the UnitedStates Dollar. The issuing authority 26 may thus manage thecryptographic exchange rate 34 between the pegged cryptographic token 28and the variable-priced cryptographic token 30, and the cryptographicexchange rate 34 drives the arbitrage that stabilizes the peggedcryptographic token 28.

As FIG. 6 further illustrates, an oracle 60 may publish the currentmarket values 44. As the market exchange 32 operates, the current marketvalues 44 of the pegged cryptographic tokens 28, the variable-pricedcryptographic token 30, and/or the reference cryptographic token 54 needto be discovered and dispersed to the market participants. Blockchainminers and other federated servers may find it inefficient tocontinuously and/or repeatedly query the market exchange 32 for currentpricing. Moreover, these pricing queries would contribute to packetcongestion in a communications network serving or accessing the marketexchange 32. Pricing stability may require a faster and simplermechanism for pricing discovery. Exemplary embodiments, then, mayutilize any query mechanism to discover the current market values 44 ofthe cryptographic tokens 28, 30, and/or 54. One or more oracle servers62, for example, may communicate with the market exchange 32 and withthe issuing authority 26. The oracle servers 62 perform an oraclefunction that provides historical and/or the current market values 44 ofthe cryptographic tokens 28, 30, and/or 54. Any participant of themarket exchange 32, and the issuing authority 26, may send a query tothe oracle server 62 and retrieve current market values 44, thecryptographic exchange rate 34, and/or the target values 24. Indeed,there may be multiple or different cryptographic exchange rates 34,perhaps reflecting value spreads when converting “VT” 30 to “PT” 28 orwhen converting “PT” 28 to “VT” 30. The market exchange 32 thusestablishes market values for the cryptographic tokens 28, 30, and/or54. The blockchain 48 may additionally or alternative publish pricinginformation as a transaction in a block 64 of data, which allows thesmart, digital contract 48 to remotely attest that the pricinginformation is accurate.

Exemplary embodiments may also permit multiple coinage trades. That is,participants in the market exchange 32 may buy and sell many differentcryptocurrencies and assets. For example, the synthetic pair 36 mayactually be associated multiple pegged cryptographic tokens 28 and/ormultiple variable-priced cryptographic tokens 30. The synthetic pair 36may thus be bought and sold as a single trade or transaction involvingthe tokens 28 and 30, and that single transaction may be recorded to theblockchain 48. Indeed, a single variable-priced cryptographic token 30may be paired with several or many pegged cryptographic tokens 28, andthe pegged cryptographic tokens 28 may be associated with differentissuing authorities 26 (such as BITCOIN®, ETHEREUM®, RIPPLE®, or othercryptographic coin mechanisms).

Pegging to the Consumer Price Index allows for a virtual distributedmarket. Coinage trades need not be between people, as exemplaryembodiments would push collateral from one pegged cryptographic token 28to another. Suppose, for example, that the pegged cryptographic token 28is tied or associated with the Dow Jones Industrial Average (“DJIA”) asa token pair against the variable-priced cryptographic token 30, gold, aBITCOIN® token, and the US Dollar. Then, if a holder wanted to be in USDollars, the holder need only push or convert value over into dollars.If the holder wanted to be in the DJIA, the holder could push andconvert into shares or holdings in the DJIA. The positional changesincrease the value of the variable-priced cryptographic token 30because, the only way in is burn the variable-priced cryptographic token30 out of existence. The holder pushes the supply down, thus increasingthe demand interest in the distributed market exchange 32. The holderhas thus necessarily created the higher price of the variable-pricedcryptographic token 30 in order to get her assets into the system.Merely buying on the market exchange 32 creates a price that allows theholder to get into the variable-priced cryptographic token 30.Furthermore, as the holder moves out of the variable-pricedcryptographic token 30 into other assets or tokens, the holdernecessarily burns the supply down. Thus, moving into the peggedcryptographic token 28 reinforces the supply of the underlyingvariable-priced cryptographic token 30.

Exemplary embodiments may also limit risk. Buying, selling, anddestroying the variable-priced cryptographic token 30 only risks thecollateral that is in the system. In other words, if the variable-pricedcryptographic token 30 is only priced at five dollars ($5.00) at a startof trading, the holder has no risk from the pegged cryptographic token28, as no pegged cryptographic token 28 exists or has been created.However, as participants buy the variable-priced cryptographic tokens30, in order to get into the pegged cryptographic token 28 system, themarket exchange 32 will push up the price of the variable-pricedcryptographic token 30. If a holder should liquidate, then obviously thesupply of the variable-priced cryptographic token 30 increases and theprice drops. So, as people don't want to have the variable-pricedcryptographic token 30, the demand 46 drops and the price lowers.However, if market participants desire the variable-priced cryptographictoken 30, they raise the price.

Trust is important. If the pricing information provided by the oracleserver 62 and/or by the blockchain 48 is untrusted or unreliable, themarket exchange 32 may fail. Trust may thus depend on any participant'sability to audit and prove the distributed nature of the oracle servers62, the historical and current market values 44 they collect over time,and the application of the pricing data to trades by the issuingauthority 26.

Additional observations on stabilization are provided. If thevariable-priced cryptographic token 30 loses significant value, tradersmay flee or liquidate and convert to the pegged cryptographic token 28(to escape the falling value of the variable-priced cryptographic token30). However, this conversion may destroy a significant quantity of thevariable-priced cryptographic tokens 30, thus reducing its supply in themarket exchange 32. A reduction in supply, in turn, may causesignificant inflation in the current market value 44 of thevariable-priced cryptographic token 30. Again, then, the destructionoperation 40 provide by exemplary embodiments helps stabilize currentmarket value 44.

The demand 46 further influences stabilization. Suppose that the utilityof the pegged cryptographic token 28 is significant, implying that manymarket participants demand ownership positions. The market participants,in other words, may want to acquire the variable-priced cryptographictoken 30 as the only gateway to create the pegged cryptographic token 28(via the destruction operation and the creation operation 38, as aboveexplained). The demand 46 for the variable-priced cryptographic token30, in other words, increases, thus increasing its current market value44. However, if the current market value 44 significantly increases,holders of the pegged cryptographic token 28 may be tempted to converttheir pegged cryptographic tokens 28 to the variable-pricedcryptographic tokens 30, particularly if the trade volume is not highand a thin market depth provides an advantage. However, such a trade onthe issuing authority tends to lower the price (e.g., the current marketvalue 44) by increasing the supply of the variable-priced cryptographictokens 30.

Exemplary embodiments may thus impose limits. At any point in time, theability to inflate the current market value 44 of the variable-pricedcryptographic token 30 is limited by the value and quantity of thepegged cryptographic token 28. Similarly, the supply of the peggedcryptographic tokens 28 is limited by the value of the variable-pricedcryptographic token 30. The stability of the pegged cryptographic token28 may thus be dependent not just on the accuracy of the oracle servers62 used by the issuing authority 26, but stability may also depend onthe extent to which the price on the market exchange 32 matches thevalue provided nu the oracle(s). In truth, prices of tokens and assetswill vary across different exchanges, and arbitrage opportunities existfor all trading as a result. The pegged cryptographic token 28 then canbe expected to be close to the value of the reference cryptographictoken 54, but unlikely to be perfectly pegged to the value of thereference cryptographic token 54.

Exemplary embodiments may introduce time delay. Trades conducted by, orordered by, the issuing authority 26 may necessarily be delayed in time,due to the time required for the oracle server(s) 62 to provide theirpricing information. This delay, especially if random, thwarts traderswho attempt to front run or anticipate upcoming, future trades by theissuing authority 26. This uncertainty may be a feature, aspredictability is necessary to game automatic systems. So, when abuy/sell order is placed, the buyer/seller may have to wait some periodof time before that order picks up the oracle price to suppress orthwart front-running. The time delay, though, may be limited or maxedout, as too long of a delay may dampen or hinder the ability of themarket exchange 32 to correct prices.

The pegged cryptographic token 28 need not traded on the market exchange32. Upon launch of the pegged cryptographic token 28, where thevariable-priced cryptographic token 30 is traded on the market exchange32, other observations may be noted. Holders of the variable-pricedcryptographic token 30 can move the variable-priced cryptographic token30 to the pegged cryptographic token 28 using the services of theissuing authority 26 to escape currency risk when the variable-pricedcryptographic token 30 is falling in value. This removes thevariable-priced cryptographic token 30 from the market exchange 32, thusreducing its market supply and supporting the current market value 44 ofthe variable-priced cryptographic token 30. At the same time, the peggedcryptographic token 28 holds its current market value 44 (perhapsrelative to its target value 24 or to the reference cryptographic token54). Exemplary embodiments thus provide a safe harbor for treasurymanagement purposes.

For example, suppose a traditional cryptocurrency “A” supports thepegged cryptographic token 28 pegged to the US Dollar. When thecryptocurrency A is slipping in value, the cryptocurrency A can beconverted to the pegged cryptographic token 28 with a simple electronicwallet transaction. It should be noted that converting thecryptocurrency A to the pegged cryptographic token 28 lowers the supplyof the cryptocurrency A, tending to support the price of thecryptocurrency A. When the price of the cryptocurrency A is rising, aparty that moved to the pegged cryptographic token 28 can move back intothe cryptocurrency A. This does cause inflation in the cryptocurrency A,so such moves will tend to lower the price of the cryptocurrency A,leading to a steadier value, and discouraging large movements from thepegged cryptographic token 28 to the cryptocurrency A. If thecryptocurrency A and the pegged cryptographic token 28 are part of aninvestment portfolio, these conversions can be done without involvingthe market exchange 32 or looking for buyers. If the cryptocurrency A isused for funding operations or paying for goods and services, the peggedcryptographic token 28 provides a logical mechanism for thesetransactions, as it has a predictable price over time.

Both the pegged cryptographic token 28 and the variable-pricedcryptographic token 30 may be traded on the market exchange 32. Forminers of operators of a public blockchain that have expenses to pay,conversion to US Dollars may be desired. However, they also have avested interest in maintaining the price of the variable-pricedcryptographic token 30. A conversion of the variable-pricedcryptographic token 30 to the pegged cryptographic token 28 supports theprice of the variable-priced cryptographic token 30 (their likely unitof support), and the pegged cryptographic token 28 can be moved to anexchange and liquidated for an expected value more easily. If thevariable-priced cryptographic token 30 is falling in value over time,the pegged cryptographic token 28 becomes an increasingly attractiveoption, and can be executed in a reasonably predictable transactioncompared to exchanges. At the same time, such conversions support theprice of the variable-priced cryptographic token 30. If thevariable-priced cryptographic token 30 is rising in price, purchasing onthe market exchange 32 will support the price, while conversion of thepegged cryptographic token 28 to the variable-priced cryptographic token30 will tend to slow gains in the variable-priced cryptographic token30. For those interested in investing in the variable-pricedcryptographic token 30, transactions in the market exchange 32 make moresense.

Exemplary embodiments may include treasury management. Any entity (suchas the market exchange 32 and/or the issuing authority 26) may allocatethe dollar-denominated pegged cryptographic token 28, plan a period ofusage, monitor market conditions, and adjust an exposure to thevariable-priced cryptographic token 30 versus the stability of thepegged cryptographic token 28. Exemplary embodiments may manage pricing,the demand 46, and supply of the variable-priced cryptographic token 30,even if no one is trading the pegged cryptographic token 28, because theprotocol (executed by the issuing authority 26) respects it.

Exemplary embodiments may also thwart sell loops. Suppose a holder ownsor holds a large amount or quantity of the cryptographic tokens 28and/or 30. The holder, of course, may sell the cryptographic tokens 28and/or 30, thus converting to some other quantity of the peggedcryptographic tokens 28. This sell operation lowers the current marketprice of the sold cryptographic tokens 28 and/or 30. Now the holder hasa resulting quantity of the pegged cryptographic tokens 28. The holdermay then withdraw the cryptographic tokens 28 and/or 30 from the marketexchange 32 (such as moving the pegged cryptographic tokens 28 to herelectronic wallet). Later in time, the holder could move the peggedcryptographic tokens 28 from her electronic wallet and exchange backinto another pegged cryptographic token 28 and/or the variable-pricedcryptographic tokens 30. This conversion inflates the supply in themarket exchange 32. In theory, then, the holder could repeat this sellscheme to attack the current market value 44 of the variable-pricedcryptographic tokens 30 and/or the pegged cryptographic token 28.However, a problem with this attack includes the fact that the attackerneeds quite a bit of funds, and the cryptographic tokens 28 and/or 30may lose value with each cycle. Moreover, the market participants maypolice actions. When the price of the variable-priced cryptographictoken 30 falls, other participants may also convert to the peggedcryptographic token 28, thus lowering the supply. This collective marketaction my even negate the attacker's sell loop attack.

Preservation of wealth prevails. The attacker is trying to inflate thevalue of the variable-priced cryptographic token 30 or the peggedcryptographic token 28, depending on position. The holder tries to sellthe variable-priced cryptographic token 30 on the market exchange 32,thus forcing down its price and acquiring the pegged cryptographic token28. The attacker may then approach the issuing authority 26 and sell thepegged cryptographic token 28 back into the variable-pricedcryptographic token 30, which inflates the supply. The attacker can thenupload the higher volume to the market exchange 32 repeat the sellcycle, as the market participants see the supply inflate and that is adownward pressure. However, this attack process also raises the supplyof variable-priced cryptographic token 30, which necessarily burns downthe supply of the pegged cryptographic tokens 28. Ultimately, then, thissell cycle would exhaust the entire supply of the pegged cryptographictokens 28, and the sell cycle costs the attacker money. The attackerwill be successful to the extent that he/she loses money. However, asthe variable-priced cryptographic tokens 30 are sold to drive down theprice, other market participants will panic and move into the peggedcryptographic tokens 28. As the price of the variable-pricedcryptographic tokens 30 falls, other market participants buy the peggedcryptographic tokens 28, thus also burning down the supply of thevariable-priced cryptographic tokens 30. So, while the attacker istrying to inflate the supply, other market participants can be workingagainst the attacker to burn the supply down. Simply put, the othermarket participants are preserving their wealth.

Exemplary embodiments may also apply to nation-state governments.Countries with hyperinflation and a central bank struggle to create aplatform by which businesses and their markets can transact. Theconditions and constraints involved vary widely from country, butexemplary embodiments may be applied by national governments to improvecurrency management. Any country with a national currency needs to haveits value stabilized, and a possible secondary token can be used tocarry out business in the immediate term. So, assume that a transactioncurrency (e.g., a “USDpeg” is a national currency pegged to the UnitedStates Dollar), implemented with an indirect pegging to the UnitedStates Dollar and managed and controlled by the central bank, is adesired solution. First, the national currency would have to beavailable on a free exchange to establish a real exchange rate with theUnited States Dollar. Second, the Central bank would provide services toconvert the national currency at the market exchange rate into theUSDpeg currency. Third, the Central bank would provide services toconvert the USDpeg currency at the market exchange rate into thenational currency. Fourth, the only mechanism to generate the USDpegcurrency would be the conversion of the national currency to the USDpegcurrency. As businesses and transactions move to the USDpeg, the supplyof the national currency would be reduced, and the value of the nationalcurrency should be supported. The concern would be for the nationalcurrency to become worthless on the market. Some amount offiscal/monetary/monetary responsibility around managing the supply ofthe national currency may be required. However, stability in businessand the market could be attained quicker and in parallel withfiscal/monetary reforms rather than putting off stability until reformsare in place.

Exemplary embodiments overcome a loss in confidence. As the reader mayunderstand, a loss in confidence in any stable token may create adownward spiral, where market forces drive value to low or even historiclows. With an indirect pegged token (such as the variable-pricedcryptographic token 30), though, the value of the pegged cryptographictoken 28 is lower than the variable-priced cryptographic token 30 thatsupports it. Arbitrage allows users to diminish the supply of the peggedcryptographic token 28 to attain more variable-priced cryptographictokens 30 from the issuing authority 26 than the trade of thevariable-priced cryptographic token 30 for pegged cryptographic token 28on the market exchange 32 allows. Arbitrage will allow the trader togain in the variable-priced cryptographic tokens 30 at the expense oflowering the supply of the pegged cryptographic token 28. While sellingthe pegged cryptographic token 28 on the market exchange 32 to get outof the pegged cryptographic token 28 will be a solution for many,exemplary embodiments provide an arbitrage opportunity for traders toprofit, but necessarily lowers the supply of the pegged cryptographictoken 28 in the process. When both the variable-priced cryptographictoken 30 and the pegged cryptographic token 28 fall in value, and thevariable-priced cryptographic token 30 falls faster than arbitrage canbe leveraged for profit, traders could shift to selling off both thevariable-priced cryptographic token 30 and the pegged cryptographictoken 28 on the exchanges, and both the variable-priced cryptographictoken 30 and the pegged cryptographic token 28 could go to zero. Thiscould happen with any issuing authority with irresponsible monetarypolicy for the variable-priced cryptographic token 30.

Still more observations are provided. Any oracle (such as an operator ofthe oracle server 62 or other service provider) may be as simple asmembers of any community polling and reporting using applicationprogramming interfaces (or “APIs”) provided by the market exchange 32.If the oracle requires time for pricing information to settle andrecord, conversions between the variable-priced cryptographic token 30and the pegged cryptographic token 28 may be delayed in order to usefuture exchange rates to avoid front running by holders watching andgaming the market. Transactions may be recorded (perhaps in theblockchain 48) at the beginning of the delay, but the transactions maybe later executed using the current price at the end of the delay. Onthe blockchain 48, the cryptocurrency exchange rate(s) 34 (perhapsgathered from the oracle server 62) may be logged over time to providean audit trail, perhaps including conversions details (e.g., time, GPSlocation, quantity, the current market price 44, and buy/sell parties)and even the time delay implemented or enforced by the issuing authority26. Because the issuing authority 26 can create the variable-pricedcryptographic token 30 as needed, the conversion of the peggedcryptographic token 28 to the variable-priced cryptographic token 30 isalways possible. Because the pegged cryptographic token 28 is desired byparties performing transactions over time, for many use cases thevariable-priced cryptographic token 30 may need to first be converted tothe pegged cryptographic token 28. This destroys the variable-pricedcryptographic token 30, while relatively simultaneously supporting thevalue of the variable-priced cryptographic token 30 by reducing thequantity or supply of the variable-priced cryptographic token 30.Arbitrage for the pegged cryptographic token 28 and/or thevariable-priced cryptographic token 30 in the exchange market 32, andcoinage conversions between the pegged cryptographic token 28 and thevariable-priced cryptographic token 30 by the issuing authority 26,maintains the value of the pegged cryptographic token 28 (perhaps at anyvalue pegged to the reference cryptographic token 54).

Even more observations are provided. Exemplary embodiments may beimplemented by any central bank. Exemplary embodiments may beimplemented by a smart contract and/or a blockchain protocol (such asthe blockchain 48). The pegged cryptographic token 28, thevariable-priced cryptographic token 30, and/or the reference token 54may be a real world currency, a cryptocurrency implemented by ablockchain, a token issued on a blockchain, or any other asset orcommodity or security as long as the issuing authority has a realisticability to issue the pegged cryptographic token 28, the variable-pricedcryptographic token 30, and/or the reference token 54 without failaccording to the creation operation 38 and the destruction operation 40(as earlier explained). In the cryptocurrency market, the concept of astable coin is a coin that has a constant value relative to one of thereal-world currencies (such as the US Dollar, Euro, Yen, Yuan, etc.). Ifthe reference token 54 is the U.S. Dollar, then the reference token 54becomes a stable coin pegged to the U.S. Dollar.

Exemplary embodiments may include transactional sharding. If implementedon a blockchain at the protocol level, transactions involving the peggedcryptographic token 28 may be restricted to a single input accountaddress to allow transactional sharding. If any cryptographic coinagetransaction specifies a single or multiple input account addresses and asingle or multiple output account addresses, then the cryptographiccoinage transaction may be transactionally sharded (e.g., eachtransactional shard handles a particular set of addresses to validate atransaction input is valid). Once the input account address has beendecremented as required as a result of the transaction, the outputaccount addresses may be updated by messaging between shards. Thisapproach requires the transaction processing mechanism of the blockchainto track and validate all shards, but a party interested in validatingthe balance of an address need only validate the updates of the addressin the shard responsible for that address. The transaction would bereferenced by all shards involved. Transactional sharding is furtherexplained by U.S. application Ser. No. 16/116,991 filed Aug. 30, 2018and entitled “Transactional Sharding of Blockchain Transactions,” whichis incorporated herein by reference in its entirety.

Yet more observations are provided. If the variable-priced cryptographictoken 30 supports multiple pegged cryptographic tokens 28 (where, forexample, one pegged cryptographic token 28 is pegged to the U.S. Dollar,another is pegged to BTC, another to the EUR, another to the price ofGold, etc.) then these synthetic pairs can be traded against each otheron exchanges. Trading of the pegged cryptographic token 28 on anyexchange (such as the market exchange 32) may have two paths forexchange to its the reference cryptographic token 54. A trading pair(such as the pegged cryptographic token 28 and the referencecryptographic token 54) would allow the reference cryptographic token 54to be purchased for the pegged cryptographic token 28. Absent a tradingpair, purchase of a liquid token (such as the BITCOIN®) could be used tosell for the reference cryptographic token 54 like the U.S. Dollar. Thepegged cryptographic token 28 may be converted to the variable-pricedcryptographic token 30 by the issuing authority 26, and thevariable-priced cryptographic token 30 moved onto an exchange and tradedfor the reference cryptographic token 54 directly, or through a liquidtoken like BITCOIN® for conversion to the reference cryptographic token54 like the U.S. Dollar. A blockchain implementation at the protocollevel has many advantages for defining and trading the peggedcryptographic token 28 because of the ability of users to audit suppliesof variable-priced cryptographic token 30 and pegged cryptographic token28, audit historical Oracle data used and Pegging Token Operations.

Exemplary embodiments thus describe decentralized, two-cryptocoinagemechanism for stability in value. Exemplary embodiments may be protocolenforced according to an algorithm, with little or no human interventionor judgment. Exemplary embodiments thus implement a monetary policy by adecentralized bank for stable cryptocurrency coinage.

FIGS. 7-10 are more detailed illustrations of an operating environment,according to exemplary embodiments. FIG. 7 illustrates the oracle server62 communicating via a communications network 70 with a protocol server72 and with a market server 74 in the blockchain environment 22. Theoracle server 62 has a processor 76 (e.g., “μP”), application specificintegrated circuit (ASIC), or other component that executes a pricingapplication 78 stored in a local, solid-state memory device 80. Theoracle server 62 has a network interface (not shown for simplicity) tothe communications network 70, thus allowing two-way, bidirectionalcommunication. The pricing application 78 includes instructions, code,and/or programs that cause the oracle server 62 to perform operations,such as sending pricing information 82 to the protocol server 72 and/orto the market server 74. The pricing information 82 may include thecurrent market values 44 and the target values 24 of the peggedcryptographic token 28 and the variable-priced cryptographic token 30.The pricing information 82 may include the cryptographic exchange rate34 between the pegged cryptographic token 28 and the variable-pricedcryptographic token 30. The oracle server 62 may feed the pricinginformation 82 on a periodic or random timing basis. However, theprotocol server 72 and/or the market server 74 may send queries via thecommunications network 70 to the network or IP address associated withthe oracle server 62, and the queries specify a query parameter thatrequests the latest and/or historical pricing information 82. The oracleserver 62 may then retrieve and send the pricing information 82 as aquery response.

FIG. 8 illustrates the protocol server 72 and the market server 74.These servers 72 and 74 may cooperate to achieve algorithmic monetarypolicy. The protocol server 72 may be operated by, or on behalf of, theissuing authority 26. The protocol server 72 has a processor 84 (e.g.,“μP”), application specific integrated circuit (ASIC), or othercomponent that executes a protocol-side stability application 86 storedin a local, solid-state memory device 88. The protocol server 72 has anetwork interface (not shown for simplicity) to the communicationsnetwork 70, thus allowing two-way, bidirectional communication. Theprotocol-side stability application 86 includes instructions, code,and/or programs that cause the protocol server 72 to perform operations,such as performing the creation operation 38 and/or the destructionoperation 40.

The market server 74 is also processor-controlled. The market server 74is operated by, or on behalf of, the market exchange 32. The marketserver 74 has a processor 90 (e.g., “μP”), application specificintegrated circuit (ASIC), or other component that executes anexchange-side stability application 92 stored in a local, solid-statememory device 94. The market server 74 has a network interface (notshown for simplicity) to the communications network 70, thus allowingtwo-way, bidirectional communication. The exchange-side stabilityapplication 92 includes instructions, code, and/or programs that causethe market server 74 to perform operations, such as performing thecreation operation 38 and/or the destruction operation 40. Theprotocol-side stability application 86 and the exchange-side stabilityapplication 92 may thus cooperate to maintain stability between thecurrent market values 44 and the target values 24 of the peggedcryptographic token 28 (“PT”) and/or the variable-priced cryptographictoken 30 (“VT”).

FIG. 9 illustrates additional details. The market server 74 receives anelectronic order 100 that specifies any cryptographic transaction (suchas a buy transaction 102 and/or a sell transaction 104). While theelectronic order 100 may be sent from any entity, FIG. 9 illustrates aparticipant server 106 operated on behalf of a market participant 108.That is, the market participant 108 is a member of the market exchange32, and the participant server 106 is registered and/or authorized tosubmit the electronic order 100 specifying a buy or sell of a quantityor number of the pegged cryptographic token 28 and/or thevariable-priced cryptographic token 30. The market server 74 obtains,reads, or retrieves the pricing information 82 and processes and/orexecutes the electronic order 100. That is, the market server 74processes and/or executes the creation operation 38 and/or thedestruction operation 40 according to the cryptographic exchange rate34.

Cryptographic conversion may occur. For example, the participant server106 may request that the market exchange 32 and/or the issuing authority26 covert a certain number of the variable-priced cryptographic token(s)30 to the pegged cryptographic token(s) 28 at the current cryptographicexchange rate 34. As another example, the participant server 106 mayrequest that the market exchange 32 and/or the issuing authority 26convert a requested number of the pegged cryptographic token(s) 28 intothe variable-priced cryptographic token(s) 30 at the currentcryptographic exchange rate 34. The market exchange 32 and/or theissuing authority 26 may thus create or destroy the variable-pricedcryptographic token(s) 30 and/or the pegged cryptographic token(s) 28,according to the creation operation 38 and/or the destruction operation40.

FIG. 10 illustrates near real time supply management. Whenever themarket server 74 receives the electronic order 100 (specifying the buytransaction 102 and/or the sell transaction 104, as FIG. 9 illustrated),the market server 74 may notify the protocol server 72. The marketserver 74, for example, may send an order notification 110 to thenetwork or Internet Protocol address associated with the protocol server72. The order notification 110 may include or specify the quantity ornumber of the pegged cryptographic token 28 and/or the variable-pricedcryptographic token 30 to be bought or sold. The order notification 110may include or specify the pricing information 82 at which the peggedcryptographic token 28 and/or the variable-priced cryptographic token 30is bought or sold. Additionally or alternatively, the protocol server 72may query the oracle server 62 for the pricing information 82.Regardless, when the protocol server 72 receives or is informed of theorder notification 110, the protocol server 72 may deposit or withdrawone or more pegged cryptographic token 28 to/from the market exchange tostabilize its current market value 44 to its target value 24. Likewise,the protocol server 72 may deposit or withdraw one or morevariable-priced cryptographic tokens 30 to/from the market exchange tostabilize its current market value 44 to its target value 24.

Exemplary embodiments may be applied regardless of networkingenvironment. Exemplary embodiments may be easily adapted to stationaryor mobile devices having cellular, wireless local area networkingcapability (such as WI-FI®), near field, and/or BLUETOOTH® capability.Exemplary embodiments may be applied to mobile devices utilizing anyportion of the electromagnetic spectrum and any signaling standard (suchas the radio spectrum and IEEE 802 family of standards, GSM/CDMA/TDMA orany cellular standard, and/or the ISM band). Exemplary embodiments,however, may be applied to any processor-controlled device operating inthe radio-frequency domain and/or the Internet Protocol (IP) domain.Exemplary embodiments may be applied to any processor-controlled deviceutilizing a distributed computing network, such as the Internet(sometimes alternatively known as the “World Wide Web”), an intranet, alocal-area network (LAN), and/or a wide-area network (WAN). Exemplaryembodiments may be applied to any processor-controlled device utilizingpower line technologies, in which signals are communicated viaelectrical wiring. Indeed, exemplary embodiments may be appliedregardless of physical componentry, physical configuration, orcommunications standard(s).

Exemplary embodiments may utilize any processing component,configuration, or system. Any processor could be multiple processors,which could include distributed processors or parallel processors in asingle machine or multiple machines. The processor can be used insupporting a virtual processing environment. The processor could includea state machine, application specific integrated circuit (ASIC),programmable gate array (PGA) including a Field PGA, or state machine.When any of the processors execute instructions to perform “operations,”this could include the processor performing the operations directlyand/or facilitating, directing, or cooperating with another device orcomponent to perform the operations.

Exemplary embodiments may packetize. When any device or servercommunicates via the communications network 70, the device or server maycollect, send, and retrieve information. The information may beformatted or generated as packets of data according to a packet protocol(such as the Internet Protocol). The packets of data contain bits orbytes of data describing the contents, or payload, of a message. Aheader of each packet of data may contain routing informationidentifying an origination address and/or a destination address.

FIGS. 11-13 illustrate a below-target scenario, according to exemplaryembodiments. Here the current market value 44 of the peggedcryptographic token 28 lags or trails its desired target value 24. Putanother way, if the pegged cryptographic token 28 is trading low, thenthe demand 46 for the pegged cryptographic token 28 is falling and lowand devalued relative to the variable-priced cryptographic token 30. Thedigital or smart contract 50 a-c, whether processed by the market server74, the protocol server 72, and/or the participant server 106,determines the buy opportunity in the pegged cryptographic token 28.Conversely, any smart contracts 50 a-c executed on behalf of holders ofthe variable-priced cryptographic token 30 see the sell opportunity toreap a profit. The smart contracts 50 may thus organize or arrange tosell or exchange a quantity of the variable-priced cryptographic tokens30 for an equivalent quantity of the pegged cryptographic tokens 28(according to the cryptographic exchange rate 34), thus realizing theprofit. The protocol server 72, perhaps acting in concert with themarket server 74, may jointly operate as a powerful stabilizing forcefor the pegged cryptographic token 28.

Stabilization may occur. Because a profit opportunity exists, the smartcontract 50 (perhaps executed by the blockchain 48) sells or exchangesthe variable-priced cryptographic tokens 30 for an equivalent quantityor number of the pegged cryptographic tokens 28 (according to thecryptographic exchange rate 34), thus realizing the profit. As thesales/exchanges are processed, a total population, quantity, or pool ofthe variable-priced cryptographic tokens 30 in the market exchange 32 isreduced (perhaps due to the destruction operation 40) and the totalpopulation, quantity, or pool of the pegged cryptographic tokens 28(e.g., a total number in usage or issuance) increases in the marketexchange 32 (perhaps due to the creation operation 38). As the coinageexchanges proceed, the issuing authority 26 and/or the market exchange32 may monitor the circulation numbers or supplies of thevariable-priced cryptographic tokens 30, the pegged cryptographic tokens28, their current market values 44, and the target value 24. If too manyvariable-priced cryptographic tokens 30 are sold or exchanged anddestroyed, there may be a greater number of the pegged cryptographictokens 28 than desired (due to the creation operation 38 and/or thedestruction operation 40) and the oversupply condition may exist,perhaps causing values to fall. Simultaneously, or nearlysimultaneously, the issuing authority 26 and/or the market exchange 32may cooperate to reduce, or withdraw, the pegged cryptographic tokens 28from the market exchange 32. The issuing authority 26, in other words,performs the destruction operation 40 to withdraw and destroy a desiredquantity of the pegged cryptographic tokens 28 from the market exchange32 to stabilize its current market value 44 to the target value 24. Atnearly the same time, the issuing authority 26 performs the creationoperation 38 to create a desired quantity of the variable-pricedcryptographic tokens 30 and injects, or deposits, the newly-createdvariable-priced cryptographic tokens 30 into the market exchange 32,thus replenishing its population supply. These trades/exchanges mayhappen without delays imposed by deposits and withdraws as long asbalances are setup ahead of time by the trader. Trades on the marketexchange 32 and with the issuing authority 26 may be executed inparallel. Once the trades are executed and recorded (perhaps to theblockchain 48), the issuing authority 26 deposits or replenishes thepopulation supply or balance of the variable-priced cryptographic tokens30 into the market exchange 32 to set the market exchange 32 up for thenext arbitrage opportunity.

Exemplary embodiments thus stabilize the pegged cryptographic token 28.Because the exchange of the pegged cryptographic token 28 for thevariable-priced cryptographic token 30 could vary greatly over time, theissuing authority 26 ensures enough variable-priced cryptographic tokens30 are injected/provided for any transaction. These variable-pricedcryptographic tokens 30 are created and the pegged cryptographic tokens28 are destroyed. Moreover, the issuing authority 26 may also create anyamount of the variable-priced cryptographic tokens 30 that are needed tomaintain an equilibrium between the current market value 44 and thetarget value 24 of the pegged cryptographic token 28.

Exemplary embodiments use market forces. If the pegged cryptographictoken 28 is trading low, then traders/holders in the market exchange 32consider the pegged cryptographic token 28 to be devalued relative tothe variable-priced cryptographic token 30. The market exchange 32 mayhave a pool of the pegged cryptographic tokens 28 and another pool ofthe variable-priced cryptographic tokens 30. The issuing authority 26(e.g., a protocol or central authority off the market exchange 32) alsohas additional pools of the pegged cryptographic tokens 28 and thevariable-priced cryptographic tokens 30. When the pegged cryptographictoken 28 is devalued by the market exchange 32, the demand 46 is low andtraders/holders will have a profit incentive to buy the peggedcryptographic token 28 at its low current market price 44, thusconverting the pegged cryptographic token 28 to its equivalent number ofvariable-priced cryptographic tokens 30 (according to the cryptographicexchange rate 34). Because the issuing authority 26 may monitor thetotal number of the variable-priced cryptographic tokens 30, the issuingauthority 26 may also, nearly simultaneously, buy an excess number ofthe variable-priced cryptographic tokens 30 to maintain a consistentsupply or pool of the variable-priced cryptographic tokens 30. Recallthat a buy order destroys the variable-priced cryptographic tokens 30and creates or gains more pegged cryptographic tokens 28. Simply put,anytime a trader/holder and/or the issuing authority 26 can make money,market forces will push the market price 44 up. An increasing marketprice 44 concomitantly increases the demand 46 of the peggedcryptographic token 28, thus bringing the current market price 44 towardthe target value 24.

As FIG. 12 illustrates, exemplary embodiments may implement algorithmicdecentralized monetary policy. Assume, again, that the current marketvalue 44 of the pegged cryptographic token 28 lags or trails its desiredtarget value 24. The protocol-side stability application 86 instructsthe protocol server 72 to compare the current market value 44 to itsdesired target value 24. When the current market value 44 (or “CMV”) isless than the target value 24 (or “TV”), a value difference 120 isnegative (e.g., [CMV-TV]<0). Because the demand 46 for the peggedcryptographic token 28 is falling or reducing, there may be too many ofthe pegged cryptographic tokens 28 in the market exchange 32 and theoversupply condition may exist. The protocol-side stability application86 may thus instruct the protocol server 72 to implement pre-programmedfiscal/monetary measures to stabilize the current market value 44 of thepegged cryptographic token 28. For example, the protocol-side stabilityapplication 86 may identify and execute a logical rule 122 that forces awithdrawal of the pegged cryptographic tokens 28 from the marketexchange 32. The logical rule 122 may thus be an algorithmic code orinstruction that is executed in response to the negative valuedifference 120 and/or the oversupply condition. The protocol server 72and the market server 74 may thus cooperate to withdraw and destroy adesired quantity of the pegged cryptographic tokens 28 from the marketexchange 32 to stimulate the demand 46 and to increase its currentmarket value 44 toward the target value 24.

As FIG. 13 illustrates, exemplary embodiments may query an electronicdatabase 124. The electronic database 124 is illustrated as beinglocally stored and maintained by the protocol server 72, but any of thedatabase entries may be stored by the market server 74 and/or at anyremote, accessible location via the communication network 70(illustrated by FIG. 7). Regardless, the electronic database 124relates, maps, or associates different values of the value difference120 to their corresponding destruction quantity 126. While theelectronic database 124 may have any logical and physical structure, arelational structure is thought perhaps easiest to understand. FIG. 13thus illustrates the electronic database 124 as a table 128 thatrelates, maps, or associates each value difference 120 to itscorresponding destruction quantity 126. So, once the value difference120 is determined, exemplary embodiments may query the electronicdatabase 124 for the value difference 120 and identify its correspondingdestruction quantity 126. While FIG. 13 only illustrates a simpleexample of a few entries, in practice the electronic database 124 mayhave many entries that detail a rich depository of different rules 122and their finely defined destruction quantities 126. Once thedestruction quantity 126 is determined, exemplary embodiments performthe destruction operation 40 to remove or delete the destructionquantity 126 of the pegged cryptographic tokens 28 from the marketexchange 32.

The creation operation 38 may also be performed. Recall that exemplaryembodiments may also monitor the total population, quantity, or pool ofthe cryptographic tokens 28 and/or 30 in the market exchange 32. Oncethe value difference 120 is determined (as above explained), the same ora different rule 122 may also be implemented to create and to injectadditional cryptographic tokens 28 and/or 30 into the market exchange32. That is, the electronic database 124 may additionally oralternatively have entries that associate the different valuedifferences 120 to different creation quantities 130. Exemplaryembodiments may thus query the electronic database 124 for the valuedifference 120 and identify its corresponding creation quantity 130.Once the creation quantity 130 is determined, exemplary embodimentsperform the creation operation 38 to deposit or inject newly-createdcryptographic tokens 28 and/or 30 into the market exchange 32. Exemplaryembodiments may implement these pre-programmed fiscal/monetary measuresto stabilize the current market value 44 of the pegged cryptographictoken 28.

FIGS. 14-15 illustrate an above-target scenario, according to exemplaryembodiments. Here the current market value 44 of the peggedcryptographic token 28 is greater or higher than its desired targetvalue 24. Demand for the pegged cryptographic token 28 is increasing, sothe pegged cryptographic token 28 may eventually be overvalued relativeto other pegged cryptographic tokens 28 and/or the variable-pricedcryptographic token 30 and/or to its target price or value 24. The smartcontract 50 may thus determine the sell opportunity to reap a profit,while other smart contracts/traders/holders see the buy opportunity. Thesmart contract 50 may sell or exchange the pegged cryptographic tokens28 for an equivalent number of the other pegged cryptographic tokens 28and/or the variable-priced cryptographic tokens 30 (according to thecryptographic exchange rate 34), thus realizing the profit. As thesales/exchanges are processed, the demand 46 for the peggedcryptographic token 28 decreases, thus reducing its current market value44 toward its target value 24. Moreover, the demand 46 for the otherpegged cryptographic tokens 28 and/or the variable-priced cryptographictoken 30 may also increase, thus increasing its current market value 44.

Population control may also be implemented. As the holders of the peggedcryptographic token 28 sell, the population pool or quantity of thepegged cryptographic tokens 28 in the market exchange 32 decreases. Asthe coinage trades proceed, the issuing authority 26 and/or the marketexchange 32 may monitor the population supplies of the other peggedcryptographic tokens 28 and/or the variable-priced cryptographic tokens30, their current market values 44, and the target values 24. If toomany pegged cryptographic tokens 28 are sold or exchanged and destroyed,there may be a greater number of the other pegged cryptographic tokens28 and/or the variable-priced cryptographic tokens 30 than desired (dueto the creation operation 38 and/or the destruction operation 40) andthe oversupply condition may exist. Simultaneously, or nearlysimultaneously, the issuing authority 26 and/or the market exchange 32may cooperate to reduce, or withdraw, the other pegged cryptographictokens 28 and/or the variable-priced cryptographic tokens 30 from themarket exchange 32. The issuing authority 26, in other words, performsthe destruction operation 40 to destroy a desired quantity of the otherpegged cryptographic tokens 28 and/or the variable-priced cryptographictokens 30 from the market exchange 32 to stabilize its current marketvalue 44 to the target value 24. At nearly the same time, the issuingauthority 26 performs the creation operation 38 to create a desiredquantity of the pegged cryptographic tokens 28 and injects, or deposits,the newly-created pegged cryptographic tokens 28 into the marketexchange 32, thus replenishing its population supply. These trades maythen be recorded to the blockchain 48.

Market forces again prevail. If the value of the pegged cryptographictoken 28 is high compared to its target value 24 and/or thevariable-priced cryptographic token 30, then the pegged cryptographictoken 28 may be sold on the market exchange 32 for the variable-pricedcryptographic token 30. This sell operation results in a greater amountof the variable-priced cryptographic tokens 30 than the peggedcryptographic token 28 should allow. At the same time, a lesser amountof the variable-priced cryptographic tokens 30 can be exchanged for thesame pegged cryptographic tokens 28 by the issuing authority 26, thusreplenishing the supply of the pegged cryptographic tokens 28 in themarket exchange 32.

As FIG. 15 illustrates, more algorithmic currency control may beimplemented. Because the current market value 44 of the peggedcryptographic token 28 exceeds its desired target value 24, the demand46 for the pegged cryptographic token 28 is increasing and may becomeovervalued. The protocol-side stability application 86 instructs theprotocol server 72 to compare the current market value 44 to its desiredtarget value 24. The value difference 120 is positive (e.g., [CMV-TV]>0)and the oversupply condition may exist. Exemplary embodiments mayimplement additional pre-programmed fiscal/monetary measures, such asexecuting one of the logical rules 122 to force a reduction orwithdrawal of the other pegged cryptographic tokens 28 and/or thevariable-priced cryptographic token(s) 30 from the market exchange 32.Once the value difference 120 is determined, exemplary embodiments mayquery the electronic database 124 for the value difference 120 andidentify its corresponding destruction quantity 126 and/or itscorresponding creation quantity 130. The protocol server 72 and themarket server 74 may thus cooperate to withdraw and destroy thedestruction quantity 126 of the other pegged cryptographic tokens 28and/or the variable-priced cryptographic tokens 30. Additionally oralternative, exemplary embodiments may perform the creation operation 38and deposit the creation quantity 130 of newly-created peggedcryptographic token 28 into the market exchange 32. Exemplaryembodiments may implement these pre-programmed fiscal/monetary measuresto stabilize the current market values 44 of the pegged cryptographictoken 28 and/or the variable-priced cryptographic token 30.

As FIGS. 11-15 illustrate, the issuing authority 26 may thus be one ofthe market participants 106. However, the issuing authority 26 mayparticipate for opposite market effects. When the issuing authority 26trades between the pegged cryptographic tokens 28 and thevariable-priced cryptographic tokens 30, the market effect of thesetrades is opposite to the trades on the market exchange 32. Suppose, forexample, that a large number of the variable-priced cryptographic tokens30 were sold for between the pegged cryptographic tokens 28 on themarket exchange 32. The price of the variable-priced cryptographic token30 necessarily goes down as the trade(s) consumes the order book for thevariable-priced cryptographic token 30. On the other hand, a largenumber of the variable-priced cryptographic tokens 30 exchanged for thepegged cryptographic tokens 28 using the issuing authority 26 reducesthe supply of the variable-priced cryptographic tokens 30 by thatamount. Lowering the supply of the variable-priced cryptographic tokens30 eventually increases the current market price 44 of thevariable-priced cryptographic tokens 30. So, as the pegged cryptographictoken 28 becomes popular as a stable value, the demand for the peggedcryptographic token 28 is likely to rise, but the only way to create abigger supply of the pegged cryptographic token 28 is through theconversation of the variable-priced cryptographic token 30 to the peggedcryptographic token 28, which lowers the supply of the variable-pricedcryptographic token 30. On the other hand, if the value of thevariable-priced cryptographic token 30 is in question and falls in themarket exchange 32, conversion to the pegged cryptographic token 28becomes attractive. All of these operations (e.g., the creationoperation 38 and the destruction operation 40) increase the value of thevariable-priced cryptographic token 30. As the value of thevariable-priced cryptographic token 30 goes up, market participants willpurchase the variable-priced cryptographic token 30 and thus furtherincrease its value. But demand may also trigger the conversion of thepegged cryptographic token 28 to the variable-priced cryptographic token30, and that conversion may dampen the growth in value of thevariable-priced cryptographic token 30 by increasing the supply.

FIG. 16 illustrates indexing of cryptographic coinage, according toexemplary embodiments. When any cryptographic token 28 and 30 is createdor destroyed (perhaps initially or via the creation operation 38 and/orthe destruction operation 40, as above explained), here exemplaryembodiments may then log the details. As a simple example, suppose theprotocol server 72 logs each creation operation 38 and each destructionoperation 40 in the electronic database 124. The electronic database 124may thus store and maintain detailed transactional records for eachpegged cryptographic token 28 and/or for each variable-pricedcryptographic token 30. Suppose, for example, that each peggedcryptographic token 28 and each variable-priced cryptographic token 30is uniquely identified with a unique token identifier 140. Moreover, theelectronic database 124 has entries that relate, associate, or map eachtoken identifier 140, its creation details 142, its deposit details 144of entry or injection into the market exchange 32, and its ownershipdetails 146 (such as buyer/seller account addresses, holder information,and/or electronic wallet details). Moreover, if the cryptographic token28 or 30 was subject to the destruction operation 40, then theelectronic database 124 may logs its corresponding destruction details148 documenting its withdrawal from the market exchange 32. Although notshown, the entries may further relate each cryptographic token 28 or 30to its corresponding pricing information 82 and the smart contract 50and/or the market server 74 that ordered or requested thebuy/sell/conversion. Exemplary embodiments may thus generate a centralrepository that indexes each cryptographic token 28 or 30 that iscreated and/or deposited into the market exchange 32. The entries mayfurther relate each cryptographic token 28 or 30 that was destroyedafter creation (according to the creation operation 38). The entries maythus fully document what tokens 28 or 30 were created, how and when andwhy, and also their destruction, if any.

The electronic database 124 may be queried for its entries. Because theelectronic database 124 may store detailed creation and destructionrecords for each pegged cryptographic token 28 and each variable-pricedcryptographic token 30, any client may send a query to the protocolserver 72 to identify related entries. As an example, a query parametermay specify the unique token identifier 140 and request itscorresponding entries (such as its date/time of creation and currentownership/holder details). A query response is sent back to the client,and the query response specifies any of the corresponding databaseentries.

FIGS. 17-18 illustrate blockchain recordations, according to exemplaryembodiments. Here, when any pegged cryptographic token 28 or anyvariable-priced cryptographic token 30 is created or destroyed,exemplary embodiments may record that creation operation 38 and/ordestruction operation 40 to the blockchain 48. The market server 74, forexample, may generate the block 64 a of data within the blockchain 48 a.The exchange-side stability application 92 may even call, invoke, and/orapply an electronic representation of a hashing algorithm 150 to any ofthe entries in the electronic database 124 and/or to the block 64 ofdata within the blockchain 48 a. The hashing algorithm 150 thusgenerates one or more hash values 152, which may be incorporated intothe blockchain 48 a. The exchange-side stability application 92 may theninstruct the market server 74 to send the blockchain 48 a to anydestination, such as the network address (e.g., Internet protocoladdress) associated with the protocol server 72.

FIG. 18 also illustrates blockchain records. When any peggedcryptographic token 28 or any variable-priced cryptographic token 30 iscreated or destroyed, that creation operation 38 and/or destructionoperation 40 may be recorded to the blockchain 48 b. The protocol server72, for example, may generate the block 64 b of data within theblockchain 48 b. The protocol-side stability application 86 may alsocall, invoke, and/or apply an electronic representation of the hashingalgorithm 150 to any of the entries in the electronic database 124and/or to the block 64 b of data within the blockchain 48 b. The hashingalgorithm 150 thus generates one or more hash values 152, which areincorporated into the blockchain 48 b.

FIGS. 19-20 illustrate a blockchain data layer 160, according toexemplary embodiments. Here the protocol server 72 may generate ablockchain data layer 160 that also documents the creation operation 38and the destruction operation 40 involving or associated with any peggedcryptographic token 28 or any variable-priced cryptographic token 30.Recall that the protocol server 72 is operated by or on behalf of theissuing authority 26 that manages the population supply of the peggedcryptographic tokens 28 and the variable-priced cryptographic tokens 30.When any token 28 or 30 is created or destroyed, whether within themarket exchange 32 or by the issuing authority 26, the correspondingcreation operation 38 and the destruction operation 40 may be documentedwithin the blockchain data layer 160. The protocol server 72 may thus betermed or called a data layer server 162 that generates the blockchaindata layer 160. The protocol-side stability application 86 may thuscall, invoke, or apply a data layer application 164 as a software moduleor subroutine that generates data records 166 in the blockchain datalayer 160. Moreover, the blockchain data layer 160 may also add anotherlayer of cryptographic hashing to generate a public blockchain 168. Theblockchain data layer 160 acts as a validation service that validatesthe smart, digital contract 50 was executed according to the creationoperation 38 and the destruction operation 40. Moreover, the blockchaindata layer 160 may generate a cryptographic proof 170. The publicblockchain 168 thus publishes the cryptographic proof 170 as a publicledger that establishes chains of blocks of immutable evidence.

The blockchain data layer 160 may be searched. Because blockchain datalayer 160 may track and/or prove any creation operation 38 and/or anydestruction operation 40, exemplary embodiments may search theblockchain data layer 160 for any query parameter. For example, theprotocol server 72 may receive queries from clients requesting the datarecords 166 within the blockchain data layer 160 that match a queryparameter. As a simple example, suppose a query specifies the tokenidentifier 140 as a query parameter. Recall that the token identifier140 uniquely identifies its corresponding pegged cryptographic token 28or variable-priced cryptographic token 30. The protocol server 72 maythen act as a query handler, determine a matching data record 166 orother entry in the blockchain data layer 160, and identify/retrieve itscorresponding contents or data or entries. As another example, suppose aquery specifies some parameter or party associated with the smartcontract 50 (such as a contract identifier that uniquely represents thesmart contract 50). The protocol server 72 may then identify/retrieveany data records 166 associated with the smart contract 50, such as thespecific pegged cryptographic token(s) 28 and the variable-pricedcryptographic token(s) 30 that were created/destroyed according to thesmart contract 50.

FIG. 20 illustrates additional publication mechanisms. Once theblockchain data layer 160 is generated, the blockchain data layer 160may be published in a decentralized manner to any destination. Theprotocol server 72 (e.g., the data layer server 162), for example, maygenerate and distribute the public blockchain 168 (via thecommunications network 70 illustrated in FIGS. 7-8) to one or morefederated servers 174. While there may be many federated servers 174,for simplicity FIG. 20 only illustrates two (2) federated servers 174 aand 174 b. The federated server 174 a and 174 b provide a service and,in return, they are compensated according to a compensation or servicesagreement or scheme.

Exemplary embodiments include still more publication mechanisms. Forexample, the cryptographic proof 170 and/or the public blockchain 168may be sent (via the communications network 70 illustrated in FIGS. 7-8)to still another server 176. The server 176 may then add another, thirdlayer of cryptographic hashing (perhaps using the hashing algorithm 150)and generate another or second public blockchain 178. While the server176 and/or the public blockchain 178 may be operated by, or generatedfor, any entity, exemplary embodiments may integrate anothercryptographic coin mechanism. That is, the server 176 and/or the publicblockchain 178 may be associated with BITCOIN®, ETHEREUM®, RIPPLE®, orother cryptographic coin mechanism. The cryptographic proof 170 and/orthe public blockchains 168 and 178 may be publicly distributed and/ordocumented as evidentiary validation. The cryptographic proof 170 and/orthe public blockchains 168 and 178 may thus be historically and publiclyanchored for public inspection and review.

FIGS. 21-25 further illustrate the blockchain data layer 160, accordingto exemplary embodiments. The blockchain data layer 160 chains hasheddirectory blocks 180 of data into the public blockchain 168. Forexample, the blockchain data layer 160 accepts input data (such as anyof the data logged in the electronic database 124, and/or the blockchain48 a sent from the market server 74 illustrated in FIG. 17) within awindow of time. While the window of time may be configurable fromfractions of seconds to hours, exemplary embodiments use ten (10) minuteintervals. FIG. 21 illustrates a simple example of only three (3)directory blocks 180 a-c of data, but in practice there may be millionsor billions of different blocks. Each directory block 180 of data islinked to the preceding blocks in front and the following or trailingblocks behind. The links are created by hashing all the data within asingle directory block 180 and then publishing that hash value withinthe next directory block.

As FIG. 22 illustrates, published data may be organized within chains182. Each chain 182 is created with an entry that associates acorresponding chain identifier 184. As a simple example, suppose thereare several market participants 108 (such as different participantservers 106, illustrated with reference to FIG. 9), and each participantserver 106 has its own corresponding chain identifier 184 a-d. Theblockchain data layer 160 may thus track any buy/sell/conversion and anyother data associated with each participant server 106 with itscorresponding chain identifier 184 a-d. As other examples, each peggedcryptographic token 28 and each variable-priced cryptographic token 30may also have its corresponding token identifier 140 and itscorresponding chain identifier 184. A unique chain 182 may thus be usedto track the buy/sell/creation/destruction events for any token 28 and30. New and old data in time may be associated with, linked to,identified by, and/or retrieved using the chain identifier 184 a-d. Eachchain identifier 184 a-d thus functionally resembles a directory 186 a-d(e.g., files and folders) for organized data entries.

FIG. 23 illustrates the data records 166 in the blockchain data layer160. As data is received as an input (such as the blockchain 48 and/orthe order notification 110 illustrated in FIGS. 10-11), data is recordedwithin the blockchain data layer 160 as an entry 190. While the data mayhave any size, small chunks (such as 10 KB) may be pieced together tocreate larger file sizes. One or more of the entries 190 may be arrangedinto entry blocks 192 representing each chain 182 according to thecorresponding chain identifier 184. New entries for each chain 182 areadded to their respective entry block 192 (again perhaps according tothe corresponding chain identifier 184). After the entries 190 have beenmade within the proper entry blocks 192, all the entry blocks 192 arethen placed within in the directory block 180 generated within oroccurring within a window 194 of time. While the window 194 of time maybe chosen within any range from seconds to hours, exemplary embodimentsmay use ten (10) minute intervals. That is, all the entry blocks 192generated every ten minutes are placed within in the directory block180.

FIG. 24 illustrates cryptographic hashing. The protocol server 72executes the data layer application 164 to generate the data records 166in the blockchain data layer 160. The data layer application 164 maythen instruct the data layer server 162 to execute the hashing algorithm150 on the data records 166 (such as the directory block 180 illustratedin FIGS. 21-23). The hashing algorithm 150 thus generates one or morehash values 152 as a result, and the hash values 152 represent thehashed data records 166. As one example, the blockchain data layer 160may apply a Merkle tree analysis to generate a Merkle root (representinga Merkle proof 170) representing each directory block 180. Theblockchain data layer 160 may then publish the Merkle proof 170 (as thisdisclosure explains).

FIG. 25 illustrates hierarchical hashing. The market server 74,generating the blockchain 48, provides a first layer 200 ofcryptographic hashing. The market server 74 may then send the blockchain48 to the protocol server 72. The protocol server 72, executing the datalayer application 164, generates the blockchain data layer 160. The datalayer application 164 may optionally provide the second or intermediatelayer 202 of cryptographic hashing to generate the cryptographic proof170. The data layer application 164 may also publish any of the datarecords 166 as the public blockchain 168, and the cryptographic proof170 may or may not also be published via the public blockchain 168. Thepublic blockchain 168 and/or the cryptographic proof 170 may beoptionally sent to a server 176 as an input to yet another publicblockchain 178 (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) for athird layer 204 of cryptographic hashing and public publication. Thefirst layer 200 and the second layer 202 thus ride or sit atop aconventional public blockchain 178 (again, such as BITCOIN®, ETHEREUM®,or RIPPLE®) and provide additional public and/or private cryptographicproofs 170.

Exemplary embodiments may use any hashing function. Many readers may befamiliar with the SHA-256 hashing algorithm. The SHA-256 hashingalgorithm acts on any electronic data or information to generate a256-bit hash value as a cryptographic key. The key is thus a uniquedigital signature. There are many hashing algorithms, though, andexemplary embodiments may be adapted to any hashing algorithm.

FIG. 26 illustrates fraud detection, according to exemplary embodiments.Here destruction is confirmed to maintain the desired quantity or numberof the pegged cryptographic tokens 28 and/or the variable-pricedcryptographic tokens 30. For example, when the market server 74 receivesthe electronic order 100 (specifying the buy transaction 102 and/or thesell transaction 104, as illustrated with reference to FIG. 9)associated with any pegged cryptographic token 28, exemplary embodimentsmay first query the electronic database 124 for the corresponding tokenidentifier 140. If an entry in the electronic database 124 associatesthe token identifier 140 to the destruction operation 40, then exemplaryembodiments may escalate the electronic order 100 for a fraud review. Inplain words, if the token identifier 140 is associated with a previousor historical destruction operation 40, then the corresponding peggedcryptographic token 28 may have already been destroyed in response to aprevious or historical buy/sell order. The pegged cryptographic token 28may have already been tagged or processed for deletion or removal fromthe market exchange 32, so its market presence may indicate a potentialfraudulent order. Regardless, if fraud is suspected or inferred,exemplary embodiments may delay or even halt processing of theelectronic order 100 for additional scrutiny.

The blockchain data layer 160 may also reveal fraudulent efforts. Again,when any electronic order 100 specifies any transaction involving anycryptographic token 28 or 30, exemplary embodiments may additionally oralternatively query the data records 166 in the blockchain data layer160 for the corresponding token identifier 140. If any data record 166contains a matching token identifier 140, the data record 166 may beretrieved and read/inspected for the destruction operation 40. If thedata record 166 logs the destruction operation 40, then exemplaryembodiments may infer that some party or market participant isattempting to buy/sell/convert a dead, destroyed, or uncirculated token28 or 30.

Fraud detection may also apply to the variable-priced cryptographictokens 30. When the electronic order 100 specifies a buy/sell of anyvariable-priced cryptographic token 30, exemplary embodiments maysimilarly query for its corresponding token identifier 140 to identifyany past or historical destruction operation 40. Again, if thevariable-priced cryptographic token 30 was previously slated fordeletion or removal from the market exchange 32, its continued marketpresence may indicate a potential fraudulent order.

Exemplary embodiments may thus track circulation of the tokens 28 and 30within the market exchange 32. Any token identifier 140 (or its hashvalue) may be compared to the entries in the electronic database 124and/or to the blockchain data layer 160. Suppose, for example, theelectronic database 124 only contains entries for active tokens 28 and30. That is, the electronic database 124 may only have entries for thepegged cryptographic tokens 28 and/or the variable-priced cryptographictokens 30 that are approved for trading in the market exchange 32. Thetoken identifiers 140 of inactive or destroyed tokens 28 and 30, inother words, may not be logged in the electronic database 124. If thetoken identifier 140 fails to match an entry in the electronic database124, then exemplary embodiments may infer that the corresponding token28 or 30 is not authorize for trades and/or was previously destroyed.

FIG. 27 illustrates monetary policy based on the blockchain data layer160, according to exemplary embodiments. As this disclosure previouslyexplained, exemplary embodiments may manage the quantities of the peggedcryptographic tokens 28 and/or the variable-priced cryptographic tokens30 within the market exchange 32 to stabilize their respective marketpricing. Moreover, as the pegged cryptographic tokens 28 and/or thevariable-priced cryptographic tokens 30 are bought, sold, created, anddestroyed, exemplary embodiments may also generate the data records 166representing the blockchain data layer 160 (such as the entries 190, theentry blocks 192, and/or the directory blocks 180 explained withreference to FIGS. 21-23). Exemplary embodiments may thus deposit and/orwithdraw the tokens 28 and 30 based on the number of the entries 190,the entry blocks 192, and/or the directory blocks 180 generated withinthe blockchain data layer 160. For example, as the data records 166 aregenerated, the protocol server 72 may determine a rate 210 ofgeneration. That is, as the data records 166 are generated when or whileexecuting trades or other transactions (such as according to the digitalcontract 50), exemplary embodiments may sum or count the entries 190,the entry blocks 192, and/or the directory blocks 180 that specify orreference a particular cryptographic token 28 and/or 30 and that aregenerated over time (such as per second, per minute, or other interval).Exemplary embodiments, for example, may call or initialize a counterhaving an initial value (such as zero). At an initial time (such as whenthe blockchain 48 is received or when a contract identifier 212 or tokenidentifier 140 is determined), the counter commences or starts countingor summing the number of the entries 190, the entry blocks 192, and/orthe directory blocks 180 (generated within the blockchain data layer160) that are commonly associated with or reference the blockchain 48,the token identifier 140 (perhaps according to the chain ID 174) and/orthe contract identifier 212. The counter stops counting or incrementingat a final time and exemplary embodiments determine or read the finalvalue or count. Exemplary embodiments may then calculate the rate 210 ofgeneration as the sum or count over time.

The rate 210 of generation may thus reflect the demand 46. As the demand46 in the market exchange 32 increases, increasing numbers of theelectronic orders 100 are being processed (regardless of the peggedcryptographic tokens 28 and/or the variable-priced cryptographic tokens30) and increasing numbers of the data records 166 are being generatedin the blockchain data layer 160. As the rate 210 of generationincreases, the protocol-side stability application 86 may infer that thedemand 46 is also increasing. The protocol-side stability application 86may thus cause the protocol server 72 to inspect the data records 166 todetermine whether the demand 46, perhaps based on the rate 210 ofgeneration, reflects the pegged cryptographic tokens 28 and/or thevariable-priced cryptographic tokens 30. Once the demand 46 isclarified, the protocol-side stability application 86 may then instructthe protocol server 72 to deposit, or to withdraw, a desired amount ofthe pegged cryptographic tokens 28 and/or the variable-pricedcryptographic tokens 30 to achieve pricing stability.

The rate 210 of generation may thus be a feedback mechanism. As the datarecords 166 are generated, the rate 210 of generation of the datarecords 166 provides advance notice of the demand 46. That is, the datarecords 166 may be generated quicker, or ahead in time, when compared toprocessing of the electronic order 100, especially if recordation to theblockchain 48 is delayed due to miner consensus. The rate 210 ofgeneration may thus be a precursor or indicator for the algorithmicmonetary policy performed by the protocol server 72.

Compensation may be due. As the protocol server 72 deposits and/ordestroys the tokens 28 and 30 in the market exchange 32, a cryptographicfee may be charged, assessed, or debited. More cryptographic fees may beassed for generating the data records 166 in the blockchain data layer160. The cryptographic fee may be paid or charged in the peggedcryptographic tokens 28, the variable-priced cryptographic tokens 30,and/or still another cryptographic coinage.

Entry credits may be required. Exemplary embodiments may impose orrequire one or more of the entry credits for depositing, or forwithdrawing, the pegged cryptographic token 28 and/or thevariable-priced cryptographic token 30 to achieve pricing stability. Theentry credits may be paid or redeemed for accessing the market server 74and/or for using the protocol server 72. The entry credits (and anyother cryptographic processing fees) thus protect the blockchainenvironment 22 from spam, numerous failed/fraudulent transactions, andother attacks.

Exemplary embodiments may include a cloud-based blockchain serviceprovided by a cloud service provider. When the creation operation 38 orthe destruction operation 40 is needed for stability, the protocolserver 72 and/or the market server 74 may outsource or subcontract thecreation operation 38 or the destruction operation 40 to the cloudservice provider. The market server 74, for example, may generate andsend a service request via the communications network 70 to the networkaddress (such as an Internet protocol address) associated with theprotocol server 72. The service request may include or specify anytransactional details associated with the electronic order 100. Theprotocol server 72 acts on information in the service request, createsand/or destroys the tokens 28 and 30, generates the data records 166 inthe blockchain data layer 160, and generates a service response. Theservice response may simply or comprehensively detail the creationoperation 38 or the destruction operation 40. The protocol server 72 andthe market server 74 may thus cooperate in a client/server fashion andcooperate to send, receive, and/or generate the service request, theservice response, and/or the data records 166 in the blockchain datalayer 160. A cryptographic fee may then be charged, assessed, ordebited.

FIGS. 28-34 further illustrate the network 220 of multiple cryptographicpegged tokens 28, according to exemplary embodiments. The network 220 ofthe cryptographic pegged tokens 28 may provide additional arbitrageopportunities within the market exchange 32. While there may be manydifferent pegged cryptographic tokens (such as any numeral N), FIG. 28only illustrates a simple example of three (3) cryptographic peggedtokens 28 a-c. Each pegged token 28 a-c may have its correspondingcurrent market value 44 a-c in the market exchange 32. Each pegged token28 a-c may also have its corresponding target value 24 a-c. Moreover,because the cryptographic pegged tokens 28 a-c may fluctuate in value,there may be multiple cryptographic exchange rates 34 whenvaluing/trading/converting between any of the cryptographic peggedtokens 28 a-c and/or the variable-priced cryptographic token 30 (asearlier explained). Even though the current market value 44 of thevariable-priced cryptographic token 30 may fluctuate, thevariable-priced cryptographic token 30 may have zero arbitrageopportunities. That is, its current market value 44 of thevariable-priced cryptographic token 30 is whatever its market value is.The current market values 44 a-c of the cryptographic pegged tokens 28a-c, however, may vary, especially when compared to each other. Forexample, suppose the current market value 44 a of the cryptographicpegged token 28 a exceeds its target value 24 a, but the current marketvalue 44 b of the cryptographic pegged token 28 b is less than itstarget value 24 b. Traders in the market exchange 32 thus see anarbitrage advantage to trade/convert/sell the cryptographic pegged token28 a to reap a profit, and the traders see a buy opportunity to acquirethe cryptographic pegged token 28 b. The traders, in other words, maysee the arbitrage opportunity is greater between the pegged tokens 28 aand 28 b as opposed to the variable-priced cryptographic token 30, whichmeans that the whole network 220 has a more enhanced stability toleverage the differences between the pegged tokens 28 a and 28 b againsteach other instead of being restricted to just the variable-pricedcryptographic token 30.

The network 220 of the cryptographic pegged tokens 28 may be traded. Anyone of the cryptographic pegged tokens 28 may be exchanged between anyother, and/or to any other, according to their relative cryptographicexchange rates 34, within the issuing authority 26 (e.g., the protocolor central authority of the market exchange 32). Indeed, the issuingauthority 26 may permit exchange/conversion as long as there is nodifference in their market values 44. If those cryptographic peggedtokens 28 are available on the protocol (e.g., the market exchange 32)and one token 28 a is high and a different token 28 b is low, anexchange (such as the high token 28 a for the low token 28 b on themarket exchange 32) may be permitted. Indeed, the same conversion may bemade inside of a user's electronic wallet. For example, suppose thecryptographic pegged token 28 a is 5% high and the cryptographic peggedtoken 28 b is 2% low. An arbitrage opportunity of 7% exists between thecryptographic pegged tokens 28 a and 28 b. The variable-pricedcryptographic token 30 would always be spot on, so the user/trader onlyhas an arbitrage opportunity of either 5% or 2%. The 2% lowcryptographic pegged token 28 b, however, may not really be adjustedbecause there is not enough room there to get a good return on thetrades because there are other costs in trading. But if an arbitrageopportunity of 7% exists, then an acceptable (perhaps minimum) return ispresent, even including trading costs/fees. That acceptable arbitrageopportunity of 7% helps to adjust the 2% low cryptographic pegged token28 b up and decrease the market value 44 of the 5% high cryptographicpegged token 28 a. The acceptable arbitrage opportunity also takesstress off of the variable-priced cryptographic token 30. Theacceptable, minimum return has a lot of variables (e.g., some may accepta profit at 1%, whereas other users may need 15% or 20% profit). If anycryptographic pegged token 28 is extremely, extremely volatile, then aparticular margin may be required to protect from the idea that it mighteither fall or increase in value before cashing out, in which case theadvantages may not be realized.

Currency-pegged tokens provides another example. Suppose Venezuela wasusing their Venezuelan dollar to back a USD cryptographic pegged token28 and they have a million percent inflation. A trader may need 20%,30%, or even 50% margin before safely trying to arbitrage because thecryptographic pegged token 28 is rapidly losing market value 44. TheArgentinian peso, which is undergoing 45% inflation per year, within anhour or two at 45% inflation over a year is not really that much, so theopportunity to arbitrage the Argentinian peso is much greater in thatsystem. The arbitrage opportunities will thus vary, and in decentralizedcryptocurrency, trades are very fast in that they settle very fast.Trades in FOREX are longer because there's a bank behind it all. Insideof an exchange may be fast, but arbitrage requires the cryptographicpegged tokens 28 to get in and out, or dollars or whatever, in and outof the exchange and those factor into trading costs.

FIG. 29 illustrates an electronic wallet 222. The electronic wallet 222is utilized by a user to buy/sell/trade/exchange her cryptographicholdings. The electronic wallet 222 is thus a software application thatis stored and executed by the user's processor-controlled device. Whilethe electronic wallet 222 may be accessed using any processor-controlleddevice, most readers are thought familiar with mobile computing. Theelectronic wallet 222 is thus a software application that is stored andexecuted by the user's smartphone 224. The user, and/or her electronicwallet 222 and smartphone 224, in other words, may be one of the marketparticipants 108 in the market exchange 32, and the electronic wallet222 and/or the smartphone 224 is/are registered and/or authorized tosubmit transactions/orders (such as the electronic order 100 explainedwith reference to FIG. 9). The smartphone 224 has a hardware processor226 that executes the electronic wallet 222 stored in a memory device228. The electronic wallet 222 may be associated with, or configuredwith, a single account address 230. The single account address 230 maythus be associated with, or related to, values or holdings in each oneof the multiple cryptographic pegged tokens 28. That is, one of themultiple cryptographic pegged tokens 28 a may be pegged or tied to USD,another one of the multiple cryptographic pegged tokens 28 b may bepegged to gold, another one of the multiple cryptographic pegged tokens28 c may be pegged to the S&P 500, another one of the multiplecryptographic pegged tokens 28 d may be pegged to Bitcoin, and stillanother one of the multiple cryptographic pegged tokens 28 e may bepegged to the Chinese Yen. Their individual price or market values 44a-e determines how conversions are performed inside of the electronicwallet 222 having the single account or address 230. The single accountor address 230 may thus be a cryptographic key to each one of theircryptographic holdings or buckets. The cryptographic key, in otherwords, may be related to the market values 44 or holdings in eachcryptographic pegged token 28 a-d and any variable-priced cryptographictoken(s) 30 (e.g., $5.00 of USD, a hundred dollars in variable token,$25 in the S&P 500, and $10 in the Chinese Yen).

FIG. 30 illustrates wallet conversions. The reader may understand acommon scenario with purchasing goods and services using cryptographicfunds. Suppose the user wants to pay a retailer (whether online orbricks-and-mortar) in Bitcoin, but the retailer denominates its goodsand pays its bills in US Dollars. The retailer may be exposed to acertain amount of currency risk, so the retailer conventionally uses anintermediary processing service (such a BitPay). The conventionalintermediary processing service accepts a cryptocurrency (such asBitcoin) and deposits US Dollars into the retailer's or merchant'saccount. Exemplary embodiments, instead, allow the user to movecryptocurrency (such as Bitcoin) value, not actual Bitcoins, into themerchant's account 232. That is, exemplary embodiments allow theuser/buyer to move Bitcoin value from her electronic wallet 222 (havingthe single account or address 230) to the address 234 representing theretailer's/merchant's cryptographic account 232. As FIG. 30 illustrates,the user's electronic wallet 222 accepts an input cryptocurrency 236 andvalue 238 and performs a cryptocurrency conversion 240 to generate anequivalent output value 242 (perhaps in US Dollars), thus eliminatingthe conventional intermediary processing service. The user may alsoinstruct or command her electronic wallet 222 and/or smartphone 224 tosend the output value 242 as a message or transaction (via thecommunications network 70 above explained) to the merchant's account 232or the merchant's address 234 (e.g., a server 244). The user thus maynot suffer the usually big disadvantage of paying/compensating theconventional third party, intermediary processing service.

FIG. 31 illustrates merchant conversions. The user/buyer may move ortransfer any cryptographic coin (such as the cryptographic pegged token28 and/or the variable-priced cryptographic token 30) from herelectronic wallet 222 (having the single account or address 230) to theaddress 234 representing the retailer's/merchant's cryptographic account232. When the retailer's/merchant's cryptographic account 232 receivesthe cryptographic coin 28/30 or value (e.g., Bitcoin payment), theretailer's/merchant's cryptographic account 232 may then perform thecryptocurrency conversion 240 to convert the crypto-payment to USDollars.

Multiple conversions may be performed. Either the user's electronicwallet 222 or the retailer's/merchant's cryptographic account 232 mayperform multiple cryptocurrency conversions 240 to convert the Bitcoinvalue to portions or percentages of US Dollars, Yen, and Euros,depending on configuration or input selections. The user's electronicwallet 222 and/or the retailer's/merchant's cryptographic account 232may thus convert any cryptographic holdings or values into othercurrencies or other cryptographic coinage (such as any of thecryptographic pegged tokens 28 and/or any variable-priced cryptographictoken 30). Exemplary embodiments shave large chunks of money off of theconversion process. Moreover, the conversion details are easilyaccountable for tax purposes because all the cryptographic exchangerates 34 and cryptotransactions are documented in the blockchain datalayer 160 and/or the blockchain 48 (as this disclosure above explained).The merchant/buyer thus has flexibility about how they hold theircryptovalue and how they accept purchases. That is, the network 220 ofthe cryptographic pegged tokens 28 is well-suited to today'sincreasingly global economy.

FIG. 32 illustrates asset-backed cryptographic pegged tokens 28. Thenetwork 220 of the cryptographic pegged tokens 28 may be based ondemand. There may be only a few cryptographic pegged tokens 28, or theremay be many cryptographic pegged tokens 28. The number of thecryptographic pegged tokens 28, and their individual pegged targetvalues 24, may be based on what has market demand and utility. If aparticular cryptographic pegged token 28 does not have market demand andutility, then it may not be worthy of trading. However, there is someadvantage to have economically independent values in the network 220 ofthe cryptographic pegged tokens 28. For example, gold may not accuratelytrack the US Dollar value, and the US Dollar value may not accuratelytrack the S&P 500. The S&P 500 may not accurately track cryptocurrencyand may not accurately commodities (like wheat or gold or oil). As themarket values 44 of these disparate things move, then arbitrageopportunities may exist to chase and manage their values. Cryptotradersmaintain stability because they understand how to trade against thesecommodities as they are reflected accurately in exchanges compared tothe market. Then, of course, assuming then that those are keeping theircryptographic pegged tokens 28, and they ae keeping their market values44 tightly, then the consumer now can leverage these various values fortransactions. As an example, suppose an airline feels that it needs tohave a thousand gallons of gas per month and a trader feels the gas ispretty cheap right now, then the trader may buy/grab the cryptographicpegged token 28 tied to gas and be able to convert it to physical gaslater. The trader may get a profit on that because its market value 44went up, but it would all be easily documented largely because,especially if this system begins to widely accepted, largely because thecryptographic pegged token 28 holds its target value 24 so tight thatthere's really no question of what the profit was during conversion fromone to the other. Simply put, the underlying asset could be anything, aslong as the asset has a market defined value. If there is not marketdefined value, or an artificial value that is guaranteed to do something(go up in value, for example), severe risks may exist because it may beguaranteed that at some point, meaning when it converts out, it alwayswins which creates inflation. Ultimately, all that inflation goes ontothe cryptographic variable token 30 and if the cryptographic variabletoken 30 isn't designed to handle that inflation, harm to the system mayoccur (in some level still depend upon the cryptographic variable token30 to reflect the value of the network 220).

Exemplary embodiments create a mechanism to exchange between assets.Exemplary embodiments may move speculators away from the assets andpeople that are investors that care, into the utility of the actualasset, which might reform a lot of the pressures inside of corporationsbecause the people that don't really care about their vote, don't reallycare about control, don't care about the issues that a company is askedabout. They're just trading on the value. This is a convenient place tohold the value and do those trades in an unrestricted way while thoseparties that really want to participate or really need to use gold orreally feel that owning the Bitcoin in my wallet is the important thing,not just playing around with its value. Those parties are the ones thatare actually setting the price and appealing to the people that careabout the utility and the long-term value is probably more critical thankowtowing to speculators who just want the price to go up. If thespeculators don't really have a vote, then they're not the party thatcompanies care about, so if you can find some place for them to live.

FIG. 33 illustrates creation and destruction. As any of the peggedcryptographic tokens 28 and the variable-priced cryptographic token 30are bought/sold/traded/exchanged, their supply may be managed using thecreation operation 38 and/or the destruction operation 40. For example,the issuing authority 26 may convert a certain number of the peggedcryptographic token 28 a into the variable-priced cryptographic token30, perhaps on demand, at the current cryptographic exchange rate 34.That is, the issuing authority 26 may perform the destruction operation40 to destroy a certain number the pegged cryptographic tokens 28 a andalso perform the creation operation 38 to create an equivalent number ofthe variable-priced cryptographic tokens 30, as determined by thecurrent cryptographic exchange rate 34. The issuing authority 26, viceversa, may perform the destruction operation 40 to destroy a certainnumber the variable-priced cryptographic tokens 30 and also perform thecreation operation 38 to create an equivalent number of the peggedcryptographic tokens 28 a. The issuing authority 26 may thus use thecreation operation 38 and/or the destruction operation 40 to maintain asupply of the pegged cryptographic tokens 28 a and/or thevariable-priced cryptographic tokens 30 as a stability mechanism.

Any one of the pegged cryptographic tokens 28 may be created anddestroyed. If needed or desired, the issuing authority 26 may convertany number of the pegged cryptographic tokens 28 b into thevariable-priced cryptographic token 30 using the creation operation 38and/or the destruction operation 40. The issuing authority 26 may alsoconvert any number of the pegged cryptographic tokens 28 c into thevariable-priced cryptographic token 30 using the creation operation 38and/or the destruction operation 40.

FIG. 34 illustrates pegged creation and destruction. As any of thepegged cryptographic tokens 28 are bought/sold/traded/exchanged, theirsupply may be managed using the creation operation 38 and/or thedestruction operation 40. For example, the issuing authority 26 mayconvert a certain number of the pegged cryptographic token 28 a into thepegged cryptographic token 28 b, perhaps on demand, at the currentcryptographic exchange rate 34. That is, the issuing authority 26 mayperform the destruction operation 40 to destroy a certain number thepegged cryptographic tokens 28 a and also perform the creation operation38 to create an equivalent number of the pegged cryptographic token 28b, as determined by the current cryptographic exchange rate 34. Theissuing authority 26, vice versa, may perform the destruction operation40 to destroy a certain number the pegged cryptographic token 28 b andalso perform the creation operation 38 to create an equivalent number ofthe pegged cryptographic tokens 28 a. The issuing authority 26 may thususe the creation operation 38 and/or the destruction operation 40 tomaintain a supply of the pegged cryptographic tokens 28 a and/or 28 b asstability mechanisms. The creation operation 38 and/or the destructionoperation 40 may also be implemented between the pegged cryptographictokens 28 a and 28 c and between 28 b and 28 c.

FIGS. 35-36 further illustrate algorithmic decentralized monetary policybased on the blockchain data layer 160, according to exemplaryembodiments. As this disclosure previously explained, exemplaryembodiments may manage the quantities of the pegged cryptographic tokens28 and/or the variable-priced cryptographic tokens 30 within the marketexchange 32 to stabilize their respective market pricing. Moreover, asthe pegged cryptographic tokens 28 and/or the variable-pricedcryptographic tokens 30 are bought, sold, created, and destroyed,exemplary embodiments may also generate the data records 166representing the blockchain data layer 160 (such as the entries 190, theentry blocks 192, and/or the directory blocks 180 explained withreference to FIGS. 21-23). Exemplary embodiments may thus deposit,withdraw, and/or convert the tokens 28 and 30 based on the number of theentries 190, the entry blocks 192, and/or the directory blocks 180generated within the blockchain data layer 160. For example, as the datarecords 166 are generated, the protocol server 72 may determine the rate210 of generation (as previously explained with reference to FIG. 27).The rate 210 of generation may thus be specified according to, or beassociated with, the digital contract 50 and/or its contract identifier212 that is referenced by the data records 166 in the blockchain datalayer 160. The rate 210 of generation may also be specified accordingto, or be associated with, any particular one of the cryptographictokens 28 and/or 30 and their corresponding token identifier 140referenced by the data records 166 in the blockchain data layer 160. Therate 210 of generation may also be specified according to, or beassociated with, the chain ID 174 referenced by the data records 166 inthe blockchain data layer 160.

The rate 210 of generation may relate to crypto-supply management. Asthis disclosure previously explained, the demand 46 for any of thepegged cryptographic tokens 28 and/or the variable-priced cryptographictokens 30 may be inferred from the rate 210 of generation of the datarecords 166 in the blockchain data layer 160 (as previously explainedwith reference to FIG. 27). As FIG. 35 illustrates, the creationoperation 38 and/or the destruction operation 40 may also be inferredfrom the rate 210 of generation of the data records 166 in theblockchain data layer 160. For example, once the rate 210 of generationis determined, exemplary embodiments may query the electronic database124 for the rate 210 of generation. The electronic database 124 isillustrated as being locally stored and maintained by the protocolserver 72, but any of the database entries may be stored by the marketserver 74 and/or at any remote, accessible location via thecommunication network 70 (illustrated by FIG. 7). Regardless, theelectronic database 124 may relate, map, or associate different valuesof the rate 210 of generation to their corresponding destructionquantities 126 and/or creation quantities 130. Again, even though theelectronic database 124 may have any logical and physical structure,FIG. 35 illustrates the relational data table 128 that relates, maps, orassociates each rate 210 of generation to its corresponding destructionquantity 126 and creation quantity 130. So, once the rate 210 ofgeneration is determined, exemplary embodiments may query the electronicdatabase 124 for the rate 210 of generation and identify itscorresponding destruction quantity 126 and creation quantity 130. WhileFIG. 35 only illustrates a simple example of a few entries, in practicethe electronic database 124 may have many entries that detail a richdepository of the different rules 122 and their finely defineddestruction quantities 126 and/or creation quantities 130. Once thedestruction quantity 126 and/or the creation quantity 130 is determined,exemplary embodiments perform the creation operation 38 and/or thedestruction operation 40, as previously explained.

Algorithmic decentralized monetary policy may be inferred from the datarecords 166 in the blockchain data layer 160. As the demand 46 for anyof the pegged cryptographic tokens (such as 28 a-c) and/or thevariable-priced cryptographic tokens 30 changes within the marketexchange 32, the rate 210 of generation of the data records 166 mayreflect the demand 46, the current market value 44, and/or the supply ofthe pegged cryptographic tokens 28 and the variable-priced cryptographictokens 30. For example, if the rate 210 of generation of the datarecords 166 is falling (or negative), the rate 210 of generation mayindicate that the current market value 44 (or “CMV”) is less than thetarget value 24 (or “TV”), the demand 46 for the correspondingcryptographic token 28 or 30 is falling or reducing, and there may betoo many of the corresponding cryptographic token 28 or 30 in the marketexchange 32, thus perhaps implying an oversupply condition may exist.The protocol-side stability application 86 may thus instruct theprotocol server 72 to implement pre-programmed fiscal/monetary measuresto stabilize the current market value 44, such as withdrawing/destroyingthe corresponding destruction quantity 126 identified in the electronicdatabase 124. The logical rule 122 may thus be an algorithmic code orinstruction that is executed in response to the falling/negative rate210 of generation. The protocol server 72 and the market server 74 maythus cooperate to withdraw and destroy a desired quantity of thecryptographic token 28 or 30 from the market exchange 32 to stimulate orincrease the rate 210 of generation and to increase its current marketvalue 44 toward the target value 24.

The creation operation 38 may also be performed. As the protocol-sidestability application 86 causes or instructs the protocol server 72 tomonitor the rate 210 of generation of the data records 166 in theblockchain data layer 160, creation and/or conversion may be implementedto inject additional cryptographic tokens 28 and/or 30 into the marketexchange 32. For example, if the rate 210 of generation of the datarecords 166 is increasing (or positive), the rate 210 of generation mayindicate that the current market value 44 (or “CMV”) is greater than thetarget value 24 (or “TV”), the demand 46 for the correspondingcryptographic token 28 or 30 is rising or increasing, and there may betoo few of the corresponding cryptographic token 28 or 30 in the marketexchange 32, thus perhaps implying an undersupply condition may exist.The protocol-side stability application 86 may thus instruct theprotocol server 72 to implement pre-programmed fiscal/monetary measuresto stabilize the current market value 44, such as injecting/creating thecorresponding creation quantity 130 identified in the electronicdatabase 124. The logical rule 122 may thus be an algorithmic code orinstruction that is executed in response to the rising/positive rate 210of generation. The protocol server 72 and the market server 74 may thuscooperate to inject and create a desired quantity of the cryptographictoken 28 or 30 from the market exchange 32 to suppress or decrease therate 210 of generation and to decrease its current market value 44toward the target value 24.

FIG. 36 shows more pre-programmed fiscal/monetary measures. Theelectronic database 124 may also have entries that relate, map, orassociate the rate 210 of generation to its corresponding destructionquantity 126, creation quantity 130, and/or conversion quantity 250.Recall that the because network 220 of multiple cryptographic peggedtokens 28 a-c may fluctuate in value, there may be pre-programmedfiscal/monetary measures to create, destroy, and/or convert between anyof the cryptographic pegged tokens 28 a-c and/or the variable-pricedcryptographic token 30 (as earlier explained). The electronic database124 may have entries that additionally relate rate 210 of generation toits corresponding conversion quantity 250. The conversion quantity 250may be a predetermined number of any of the cryptographic pegged tokens28 a-c that is converted into another one of the cryptographic peggedtokens 28 a-c (perhaps according to the corresponding cryptographicexchange rate 34). The conversion quantity 250 may additionally oralternatively specify a predetermined number of any of the cryptographicpegged tokens 28 a-c that is converted into the variable-pricedcryptographic token 30. Regardless, once the rate 210 of generation isdetermined and the conversion quantity 250 is identified, exemplaryembodiments may conduct cryptocurrency conversions as furtherpre-programmed fiscal/monetary measures.

Pre-programmed stimulus may be implemented. If the rate 210 ofgeneration of the data records 166 is falling (or negative), the rate210 of generation may indicate that the current market value 44 (or“CMV”) of the cryptographic pegged token 28 a is less than its targetvalue 24 (or “TV”), its demand 46 is falling or reducing, and there maybe too many of the cryptographic pegged tokens 28 a in the marketexchange 32, thus perhaps implying an oversupply condition may exist.The protocol-side stability application 86 may thus instruct theprotocol server 72 to implement pre-programmed fiscal/monetary measures,such as converting the corresponding conversion quantity 250 of thecryptographic pegged tokens 28 a into the different cryptographic peggedtoken 28 b (perhaps according to the corresponding cryptographicexchange rate 34). The logical rule 122 implementing the conversionquantity 250 is executed in response to the falling/negative rate 210 ofgeneration of the data records 166. The protocol server 72 and themarket server 74 may thus cooperate to convert a desired quantity of thecryptographic pegged tokens 28 a-c to stimulate or increase the rate 210of generation and to increase its current market value 44 toward thetarget value 24.

Crypto-supply may be managed. When the rate 210 of generation of thedata records 166 is increasing (or positive), the rate 210 of generationmay indicate that the current market value 44 (or “CMV”) of thecryptographic pegged token 28 a is greater than its target value 24 (or“TV”), the demand 46 for the cryptographic pegged token 28 a is risingor increasing, and there may be too few of the correspondingcryptographic pegged token 28 a in the market exchange 32, thus perhapsimplying an undersupply condition may exist. The protocol-side stabilityapplication 86 may thus instruct the protocol server 72 to implementpre-programmed fiscal/monetary measures to stabilize the current marketvalue 44, such as converting the conversion quantity 250 of thedifferent cryptographic pegged tokens 28 b into the cryptographic peggedtoken 28 a (perhaps according to the corresponding cryptographicexchange rate 34). The logical rule 122 may thus be an algorithmic codeor instruction that is executed in response to the rising/positive rate210 of generation. The protocol server 72 and the market server 74 maythus cooperate to inject new cryptographic pegged tokens 28 a into themarket exchange 32 to suppress or decrease the rate 210 of generationand to decrease its current market value 44 toward the target value 24.

FIG. 37 is a flowchart illustrating a method or algorithm for stablepricing of cryptographic coinage, according to exemplary embodiments.The electronic orders 100 are recorded (Block 300) and the data records166 in the blockchain data layer 160 are generated (Block 302). The rate210 of generation is determined (Block 304) and the destruction quantity126 (Block 306), the creation quantity 130 (Block 308), and theconversion quantity 250 (Block 310) are identified. The destructionoperation 40 may be performed (Block 312) to remove and destroy aquantity of the pegged cryptographic token 28 from the market exchange32. The creation operation 38 may be performed (Block 314) to create anddeposit a quantity of a different pegged cryptographic token 28 into themarket exchange 32. A conversion operation of the conversion quantity250 may be performed (Block 316) to increase or decrease any of thepegged cryptographic tokens 28 in the market exchange 32. More datarecords 166 in the blockchain data layer 160 are generated (Block 318)to document the destruction quantity 126, the creation quantity, and theconversion quantity 250. The data records 166 may be hashed (Block 320)and incorporated into the public blockchain (Block 322).

FIG. 38 is a schematic illustrating still more exemplary embodiments.FIG. 38 is a more detailed diagram illustrating a processor-controlleddevice 350. As earlier paragraphs explained, the protocol-side stabilityapplication 86, the market-side stability application 86, and/or thedata layer application 164 may partially or entirely operate in anymobile or stationary processor-controlled device. FIG. 38, then,illustrates the protocol-side stability application 86, the market-sidestability application 86, and/or the data layer application 164 storedin a memory subsystem of the processor-controlled device 350. One ormore processors communicate with the memory subsystem and executeeither, some, or all applications. Because the processor-controlleddevice 350 is well known to those of ordinary skill in the art, nofurther explanation is needed.

FIG. 39 depicts other possible operating environments for additionalaspects of the exemplary embodiments. FIG. 39 illustrates theprotocol-side stability application 86, the market-side stabilityapplication 86, and/or the data layer application 164 operating withinvarious other processor-controlled devices 350. FIG. 39, for example,illustrates that the protocol-side stability application 86, themarket-side stability application 86, and/or the data layer application164 may entirely or partially operate within a set-top box (“STB”) orother media player (352), a personal/digital video recorder (PVR/DVR)354, a Global Positioning System (GPS) device 356, an interactivetelevision 358, a tablet computer 360, or any computer system,communications device, or processor-controlled device utilizing any ofthe processors above described and/or a digital signal processor(DP/DSP) 362. Moreover, the processor-controlled device 350 may alsoinclude wearable devices (such as watches), radios, vehicle electronics,cameras, clocks, printers, gateways, mobile/implantable medical devices,and other apparatuses and systems. Because the architecture andoperating principles of the various devices 350 are well known, thehardware and software componentry of the various devices 350 are notfurther shown and described.

Exemplary embodiments may be applied to any signaling standard. Mostreaders are thought familiar with the Global System for Mobile (GSM)communications signaling standard. Those of ordinary skill in the art,however, also recognize that exemplary embodiments are equallyapplicable to any communications device utilizing the Time DivisionMultiple Access signaling standard, the Code Division Multiple Accesssignaling standard, the “dual-mode” GSM-ANSI Interoperability Team(GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signalingstandard. Exemplary embodiments may also be applied to other standards,such as the I.E.E.E. 802 family of standards, the Industrial,Scientific, and Medical band of the electromagnetic spectrum,BLUETOOTH®, and any other.

Exemplary embodiments may be physically embodied on or in acomputer-readable non-transitory storage medium. This computer-readablemedium, for example, may include CD-ROM, DVD, tape, cassette, floppydisk, optical disk, memory card, memory drive, and large-capacity disks.This computer-readable medium, or media, could be distributed toend-subscribers, licensees, and assignees. A computer program productcomprises processor-executable instructions for pricing stability ofcryptographic coins, as the above paragraphs explain.

While the exemplary embodiments have been described with respect tovarious features, aspects, and embodiments, those skilled and unskilledin the art will recognize the exemplary embodiments are not so limited.Other variations, modifications, and alternative embodiments may be madewithout departing from the spirit and scope of the exemplaryembodiments.

1. A method performed by a server that stabilizes values associated withcryptographic coins, the method comprising: receiving, by the server, acryptographic coinage transaction conducted via a computer networkbetween computers specifying a cryptographic token and a differentcryptographic token; monitoring, by the server, the values associatedwith the cryptographic token and the different cryptographic token;adjusting, by the server, the values of the cryptographic token and thedifferent cryptographic token by executing a creation operation thatcreates the cryptographic token and injects the cryptographic token intothe computer network; and in response to the creation operation,performing, by the server, a destruction operation by removing thedifferent cryptographic token from the computer network.
 2. The methodof claim 1, further comprising monitoring a population supply of thecryptographic token in the computer network.
 3. The method of claim 1,further comprising monitoring a population supply of the differentcryptographic token in the computer network.
 4. The method of claim 1,further comprising logging the destruction operation.
 5. The method ofclaim 1, further comprising logging the creation operation.
 6. Themethod of claim 1, further comprising adding a database entry to anelectronic database that associates the different cryptographic coinagetransaction with the destruction operation.
 7. The method of claim 1,further comprising adding a database entry to an electronic databasethat associates the cryptographic coinage transaction with the creationoperation.
 8. A system that stabilizes values associated withcryptographic coins, the system comprising: a hardware processor; and amemory device storing instructions that when executed by the hardwareprocessor perform operations, the operations comprising: receiving acryptographic coinage transaction conducted via a computer networkbetween computers specifying a pegged cryptographic token and adifferent pegged cryptographic token; monitoring the values associatedwith the pegged cryptographic token and the different peggedcryptographic token; adjusting the values of the pegged cryptographictoken and the different pegged cryptographic token by converting thepegged cryptographic token into the different pegged cryptographic tokenaccording to the values; and executing a creation operation that injectsthe different pegged cryptographic token into the computer network. 9.The system of claim 8, wherein the operations further comprisemonitoring a population supply of the pegged cryptographic token in thecomputer network.
 10. The system of claim 8, wherein the operationsfurther comprise monitoring a population supply of the different peggedcryptographic token traded in the computer network.
 11. The system ofclaim 8, wherein the operations further comprise logging the creationoperation.
 12. The system of claim 8, wherein the operations furthercomprise identifying a conversion quantity associated with theconverting of the pegged cryptographic token into the different peggedcryptographic token.
 13. The system of claim 8, wherein the operationsfurther comprise adding a database entry to an electronic database thatassociates the cryptographic coinage transaction with the creationoperation.
 14. The system of claim 8, wherein the operations furthercomprise adding a database entry to an electronic database thatassociates the values with the creation operation.
 15. A memory devicestoring instructions that when executed by a hardware processor performoperations, the operations comprising: receiving a blockchain specifyingcryptographic coinage transactions conducted via a computer networkbetween computers, the cryptographic coinage transactions associatedwith a pegged cryptographic token and a different pegged cryptographictoken; monitoring values associated with the pegged cryptographic tokenand the different pegged cryptographic token; in response to the values,converting the pegged cryptographic token into the different peggedcryptographic token; and injecting the different pegged cryptographictoken into the computer network.
 16. The memory device of claim 15,wherein the operations further comprise monitoring a population supplyof the pegged cryptographic token in the computer network.
 17. Thememory device of claim 15, wherein the operations further comprisemonitoring a population supply of the different pegged cryptographictoken traded in the computer network.
 18. The memory device of claim 15,wherein the operations further comprise logging the converting of thepegged cryptographic token into the different pegged cryptographictoken.
 19. The system of claim 8, wherein the operations furthercomprise identifying a conversion quantity associated with theconverting of the pegged cryptographic token into the different peggedcryptographic token.
 20. The system of claim 8, wherein the operationsfurther comprise adding a database entry to an electronic database thatassociates the values with the converting of the pegged cryptographictoken into the different pegged cryptographic token.